Why does php password_hash() generate different hashes for the same input? I've been using password_hash('password', PASSWORD_DEFAULT) for an internal system, and while I was testing the code, I saw that it generated different hashes for the same input.

Why does this happens, and how do password_verify() identify another hash as the same password if the hashes are different?

Is there an explanation about it's 'safeness'?

like the documentation of password_hash states, a unique salt is being calculated for each time it is called.

  It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one.

(source: php manual - password_hash)

Additionally the used options of the hashing process are stored in the generated hash itself(salt,cost,algo) so the password_verify has all information's it needs to verify if a plaintext matches a hash without being able to decrypt it.

  Note that password_hash() returns the algorithm, cost and salt as part of the returned hash. Therefore, all information that's needed to verify the hash is included in it.

(source: enter link description here)

This also explains why the start of most hashes are identical.
For example depending on the cost and algo used your hashes might always start with something like $2y$10$ and from then on differ. This behavior can however change between different frameworks, algorithms or other factors, so take this only as a example of how the cost and algo can be saved in the resulted hash.


I provided lots of un-encrypted personal data to Google Drive over the years. How can I best retake control over my data? I am an average user of the internet, with my very legal, normal and humble private life. Over the years I have uploaded all kinds of personal data to Google Drive, and I'm regretting this decision, because of the loss of power over my privacy that it entails.

I would like to regain control over that data as much as possible.

What are my prospects of improving this situation?

Could I reasonably take out the data, encrypt it, and re-upload it to Google or another storage service to make it less likely that hackers, rogue Google employees, or any rogue authority can access it?

I went through this recently and completely de-Googled everything. I will try to answer your questions with a bit of my own experience.

  What are my prospects of improving this situation?

Google has a cute little "take back my privacy" feature that is at best a socially awkward joke with an offensive punch line. It's just there to give advocates the warm fuzzy - don't think for a second it does any real good. The alternative therefore, is to move away entirely.

If you're going to move away from Google's prying eyes (and I fully support this) it comes with some sacrifices but is well worth it.

The best way to begin is to import your docs into something like Zoho or disroot hosting providers and are much more privacy friendly. Zoho has a very user-friendly application that will basically upload your entire Google Drive for you and make migration very, very easy. It also has the ability like Google Docs to collaborate online with others and edit via URL. Disroot is not as mature of an organization, but has very high regards for privacy and also is an Email provider. I bought a domain through GoDaddy as as registrar and moved my Email to protonmail, a Swiss company renowned for both their mail and VPN services (although I use VyprVPN instead.... for now). You can use a custom domain or keep the protonmail.com domain, if you'd like.

Ditch Chrome for Firefox and use DuckDuckGo as your search engine. This part might be the most crucial regarding Google's collection of information about you, even if you did not ask about this.

Finally, privacy from Google Docs is near worthless if you use an Android because they will accumulate most of your personal information anyway. You can  install Copperhead OS on your Android phone which completely and utterly removes ALL google services and is built for the ultimate privacy (if not always convenience). You may opt for Waze or Nokia's "Here" instead of Google Maps. I traded Google Play for F-Droid and Aptoide. Finally, I traded Youtube for NewPipe and actually love the "play in background" feature.

  Could I reasonably take out the data, encrypt it, and re-upload it to Google or another storage service to make it less likely that hackers, rogue Google employees, or any rogue authority can access it?

You could, but that would not serve much purpose. They still have your data and your encryption is probably no match for Google's engineers assuming they actually wanted it, and Google keeps a lot of metadata, meaning that while your individual documents 'might' be safe, your video consumption and music habits on youtube, driving history on maps, search history, doctors appointments, emails, etc is all kept as well assuming you use other google services.

If you REALLY want to erase ALL of your data, start looking in to and using tools found here and start doing a reverse google search on yourself. There are quite a few companies who aggregate and sell your data (persopo, radaris, etc), so you will need to go through them one by one and request that your records be deleted. It's time consuming, but if you're in IT security especially, it's well worth it.

Finally, consider how important social media is to you, because besides Google and the US government, Facebook is the biggest privacy violator out there, and LinkedIn and others are not far behind. (NOTE - I may be a hypocrite but I keep LinkedIn still. Tinfoil hatters gotta eat too!)

This may be extreme measures for you, and that's understandable - privacy and convenience has a trade off.


Security devices other than firewall and IDS I was just studying about firewalls and IDS/IPS and had a doubt. Are these the only two major security devices that a company invests in? or are there other equipment and security controls?

There are few other choices.  If software is inherently insecure, all you can do is to replace it with something that isn't; or wrap it up in a condom of some sort.  Host-based systems require programs to be invasively, and cooperatively, installed on every client (virus scanners, local network stack IPS).  Network-based systems don't require cooperation from the clients, and try to fix security by parsing traffic.  Some network-based systems require a little bit of cooperation by blocking encrypted traffic for connections that don't submit to scrutiny; and accept the company/ISP's certificate authority (so that the authority at the local boundary can inspect the traffic).


Is it good practice if all programs have their own user ID? Typically, each physical user on a system has an ID, and a running process is run as the user who starts it. This means the process is able to access all of the user's files, even those that not intended for this specific program. For example, if you start running Firefox then it has access to Chrome config files, and vice versa. But as you can see this is irrational because any browser works correctly without access to another's config files.

This is also dangerous if you consider one malicious program a user starts is enough to stealthily modify all of the user's files, plus send emails to other people as the user, access web accounts if the user stores a cookie, and many other possible undesirable behaviors. The root cause is that the process is running as the user, not as itself.

The problem has been partially remedied in commodity Linux systems by specifying UID and GID when starting a process. While this is true for many system daemons, it is not the typical case for client softwares. Many utilities such as browers, FTP clients, text editors are run as the user but not their own UID.

The OS which seeks an OS-level solution is Android, in which every app has its own ID and accesses user's data through permissions. It adds some complexity but prevents a lot of attack possibilities. If this is seen as good practice, then why isn't this feature ported to desktop Linux (Or has it)? With wider deployment of systemd, users are now having much better control of the processes they run and there shouldn't be technical difficulties in implementing such a feature.

The question reverses the problem. Subsystem isolation exists for a long time in server OS through specific UIDs. You can even go one step further with virtual machines or jails in BSD systems.

For the client programs part, the desktop OS way is to split the program in two parts, an human interface that runs under the used id, and a daemon (or service in Windows world) that can run under its own id (think of databases like PostgreSQL for example).

So the security is in the hand of the system administrator who can choose a security pattern adapted to the sensitivity of the appliation/data.

But in Android, you have no access to an administrative account, so the end user cannot configure any security pattern. So the solution was to declare an user id by application vendor (note by vendor not by application!) in order to limit the damages caused by one application to applications of the same developper.

In the opposite, until the most recent Android versions, the end user could not choose to limit what an application could access: if the developper choosed to ask access to the contact directory, the user could not do anything against it except not installing the application.

So my answer is that one user id per application has no mean to be added to normal OSs because it is already present for a long time (provided devs make use of it). But maybe Android system will add features to allow the end user to control more finely what applications are allowed to do


Can a man in the middle hear half the HTTPS conversation Given a conversation is occurring using HTTPS, during the handshake, can the man in the middle interpret all communication from the server to the client?

Assuming that the man in the middle can receive the packet, and open it (using the public key), could it then pass the unmodified (encrypted) packet which it received from the server? It would receive back a packet encrypted using the public key (which it would not be able to interpret), but would this allow the man in the middle to eavesdrop half the conversation?

No. A cryptographic system that only protected half of the information would just be slightly better than useless.

During the handshake, a symmetric key is exchanged. After the handshake, that symmetric key is used to encrypt all data (usually with AES). So without that symmetric key you are toast - you can not read 50%, you can read 0%.

When RSA is used for key exchange, the client encrypts a random symmetric key with the servers public key. Since the attacker does not know the servers private key, she can not decrypt it.

When Diffie-Hellman is used for key exchange, it also makes it possible to establish a symmetric key without an eavesdropper being able to get it.


Can going to a bad website on firefox, or installing a malcious firefox plugin, infect other parts of my home folder on a Linux system? BTW, I don't mean root, just a plain user. I'm worried because I'm scared that if I do such things I could infect my Chromium folder. I got a huge case of OCD.

The short answer is: if your Firefox is compromised, it can do whatever it wants. It can modify whatever files it wants. It can even keylog and get root. But there are a few ways you can improve your security, like using a more secure browser, AppArmor or the NoScript plugin. The long answer is...

Yes, if your Firefox process is compromised, it can do absolutely anything your regular user can do. In Linux, security comes from separation of users. I talked a little about the risks of assuming you have intra-user protection here. Basically, your system has security checks all over, and if two process' are of the same user, then they are considered to be equally trusted, and can interfere with each other at will. This includes keylogging, which means they can sniff your root password next time you type it in. Or it could inject keystrokes, move the mouse, modify all files in your home directory and many files outside of it. It could access the network at will, and pretty much everything else. If your Firefox process is compromised, you have much more to worry about than your Chromium folder being modified. Firefox runs as your user. Your user is you. Malware that breaks out of Firefox inherits that privilege, and will be able to do whatever you can do, such as the few examples I gave above.

Also note that Chromium is significantly more secure than Firefox. While Firefox has no proactive security mechanisms whatsoever, Chromium has them in abundance (suid chroot sandbox, seccomp-bpf sandbox, several types of namespace sandboxes, and more). In many contents, Firefox is almost always the first to be hacked, with Chrome/Chromium surviving the longest, and taking the longest for world-expert hackers to find ways through all the sandbox layers. If your primary goal is security, you might want to stick with using just Chromium.

If you still want to use Firefox though, you get mitigate this to a large extent by using a sandbox that comes with Linux. Ubuntu has the AppArmor sandbox, so you can use it to protect your browsers, among other things. I don't know how up to date it is, but the instructions for enabling it can be found here. AppArmor is a type of sandbox called a MAC, or Mandatory Access Control, which is controlled by the kernel, the core and boss of the operating system which runs with even more privileges than root. When an AppArmor profile is enabled, it tells the kernel to restrict what folders and files a process is allowed to access. The AppArmor profile for Firefox is written to give it only the permissions it needs, and nothing else. If it tries to access anything it's not allowed to, the kernel will promptly deny access.

Here is the default Firefox AppArmor policy for Ubuntu 14.04, which you can look at to get an idea of how it works. As you can see, it allows read access to most folders, but only allows writing to configuration folders related to Firefox. Chromium folders are not in the whitelisted paths, and any attempts to write there would be denied.

# vim:syntax=apparmor
# Author: Jamie Strandboge <jamie@canonical.com>

# Declare an apparmor variable to help with overrides
@{MOZ_LIBDIR}=/usr/lib/firefox

#include <tunables/global>

# We want to confine the binaries that match:
#  /usr/lib/firefox/firefox
#  /usr/lib/firefox/firefox
# but not:
#  /usr/lib/firefox/firefox.sh
/usr/lib/firefox/firefox{,*[^s][^h]} {
  #include <abstractions/audio>
  #include <abstractions/cups-client>
  # TODO: finetune this for required accesses
  #include <abstractions/dbus>
  #include <abstractions/dbus-accessibility>
  #include <abstractions/dbus-session>
  #include <abstractions/gnome>
  #include <abstractions/ibus>
  #include <abstractions/nameservice>
  #include <abstractions/p11-kit>

  # Addons
  #include <abstractions/ubuntu-browsers.d/firefox>

  # for networking
  network inet stream,
  network inet6 stream,
  @{PROC}/[0-9]*/net/if_inet6 r,
  @{PROC}/[0-9]*/net/ipv6_route r,
  @{PROC}/[0-9]*/net/dev r,
  @{PROC}/[0-9]*/net/wireless r,

  # should maybe be in abstractions
  /etc/ r,
  /etc/mime.types r,
  /etc/mailcap r,
  /etc/xdg/*buntu/applications/defaults.list    r, # for all derivatives
  /etc/xfce4/defaults.list r,
  /usr/share/xubuntu/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/mimeapps.list r,
  owner @{HOME}/.local/share/applications/mimeinfo.cache r,
  owner /tmp/** m,
  owner /var/tmp/** m,
  /tmp/.X[0-9]*-lock r,
  /etc/udev/udev.conf r,
  # Doesn't seem to be required, but noisy. Maybe allow 'r' for 'b*' if needed.
  # Possibly move to an abstraction if anything else needs it.
  deny /run/udev/data/** r,

  /etc/timezone r,
  /etc/wildmidi/wildmidi.cfg r,

  # firefox specific
  /etc/firefox*/ r,
  /etc/firefox*/** r,
  /etc/xul-ext/** r,
  /etc/xulrunner-2.0*/ r,
  /etc/xulrunner-2.0*/** r,
  /etc/gre.d/ r,
  /etc/gre.d/* r,

  # noisy
  deny @{MOZ_LIBDIR}/** w,
  deny /usr/lib/firefox-addons/** w,
  deny /usr/lib/xulrunner-addons/** w,
  deny /usr/lib/xulrunner-*/components/*.tmp w,
  deny /.suspended r,
  deny /boot/initrd.img* r,
  deny /boot/vmlinuz* r,
  deny /var/cache/fontconfig/ w,
  deny @{HOME}/.local/share/recently-used.xbel r,

  # TODO: investigate
  deny /usr/bin/gconftool-2 x,

  # These are needed when a new user starts firefox and firefox.sh is used
  @{MOZ_LIBDIR}/** ixr,
  /usr/bin/basename ixr,
  /usr/bin/dirname ixr,
  /usr/bin/pwd ixr,
  /sbin/killall5 ixr,
  /bin/which ixr,
  /usr/bin/tr ixr,
  @{PROC}/ r,
  @{PROC}/[0-9]*/cmdline r,
  @{PROC}/[0-9]*/mountinfo r,
  @{PROC}/[0-9]*/stat r,
  owner @{PROC}/[0-9]*/task/[0-9]*/stat r,
  @{PROC}/[0-9]*/status r,
  @{PROC}/filesystems r,
  /sys/devices/pci[0-9]*/**/uevent r,
  owner @{HOME}/.thumbnails/*/*.png r,

  /etc/mtab r,
  /etc/fstab r,

  # Needed for the crash reporter
  owner @{PROC}/[0-9]*/environ r,
  owner @{PROC}/[0-9]*/auxv r,
  /etc/lsb-release r,
  /usr/bin/expr ix,
  /sys/devices/system/cpu/ r,
  /sys/devices/system/cpu/** r,

  # about:memory
  owner @{PROC}/[0-9]*/statm r,
  owner @{PROC}/[0-9]*/smaps r,

  # Needed for container to work in xul builds
  /usr/lib/xulrunner-*/plugin-container ixr,

  # allow access to documentation and other files the user may want to look
  # at in /usr and /opt
  /usr/ r,
  /usr/** r,
  /opt/ r,
  /opt/** r,

  # so browsing directories works
  / r,
  /**/ r,

  # Default profile allows downloads to ~/Downloads and uploads from ~/Public
  owner @{HOME}/ r,
  owner @{HOME}/Public/ r,
  owner @{HOME}/Public/* r,
  owner @{HOME}/Downloads/ r,
  owner @{HOME}/Downloads/* rw,

  # per-user firefox configuration
  owner @{HOME}/.{firefox,mozilla}/ rw,
  owner @{HOME}/.{firefox,mozilla}/** rw,
  owner @{HOME}/.{firefox,mozilla}/**/*.{db,parentlock,sqlite}* k,
  owner @{HOME}/.{firefox,mozilla}/plugins/** rm,
  owner @{HOME}/.{firefox,mozilla}/**/plugins/** rm,
  owner @{HOME}/.gnome2/firefox*-bin-* rw,
  owner @{HOME}/.cache/mozilla/{,firefox/} rw,
  owner @{HOME}/.cache/mozilla/firefox/** rw,
  owner @{HOME}/.cache/mozilla/firefox/**/*.sqlite k,

  #
  # Extensions
  # /usr/share/.../extensions/... is already covered by '/usr/** r', above.
  # Allow 'x' for downloaded extensions, but inherit policy for safety
  owner @{HOME}/.mozilla/**/extensions/** mixr,

  deny @{MOZ_LIBDIR}/update.test w,
  deny /usr/lib/mozilla/extensions/**/ w,
  deny /usr/lib/xulrunner-addons/extensions/**/ w,
  deny /usr/share/mozilla/extensions/**/ w,
  deny /usr/share/mozilla/ w,

  # Miscellaneous (to be abstracted)
  # Ideally these would use a child profile. They are all ELF executables
  # so running with 'Ux', while not ideal, is ok because we will at least
  # benefit from glibc's secure execute.
  /usr/bin/mkfifo Uxr,  # investigate
  /bin/ps Uxr,
  /bin/uname Uxr,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/usr.bin.firefox>
}

Another way to mitigate this is by using NoScript. It allows you to block dangerous JavaScript, Flash, etc from websites, which makes attacks on Firefox much less likely to succeed. Even if you keep most scripts enabled because disabling scripts causes many websites to not work as expected, the plugin still provides transparent protection from other threats, such as clickjacking and XSS. It's a very popular plugin and very well regarded in the security community. I highly recommend you install it, in addition to enabling AppArmor, if your goal is to minimize the risk of a malicious website compromising your computer or any files on it.


Protecting myself in Ukraine I am a United States citizen planning a week-long trip to Ukraine. A friend advised me that Internet security is less-than-great there. What steps should I take to protect myself if I use public or hotel wifi connections for my smart phone and laptop while there?  Anything different than I would do in the US?  (which right now is limited to common sense and not sending important information on non-HTTPS sites)

As ott mentioned & let me reinforce it: Use a VPN! Especially for email sign in and banking. It's best to use it for any login activities. A traveller named Nomadic Matt wrote a couple of good articles to help you pick out which is the best for you:

Everything You Need To Know About VPNs for Travel (HINT: if you are traveling with a phone and a laptop, choose a provider that supports multiple devices)

The No-Nonsense Guide to Data Security for Travelers

Other things to do:

I personally bring a couple of small new storage USB drives (>4GB) as throw aways in case I have to print from at an internet cafe. In foreign countries, these computers can be riddled with viruses.
Have a PIN code on your mobile devices. If it supports swipe, it has been shown that grease prints make it fairly easy to re-create your pattern. Also turn on feature to wipe after a limited number of incorrect attempts.
Make sure you are using encryption on your phone (SD card included) and full-disk encryption for your computer. Have these devices turned off when entering the country and passing through customs (beware that you may be asked to turn on and decrypt).
Consider limiting the data that you take to the country. If you don't need it, leave it at home with your back-ups.
Phone theft (esp. these nice shiny expensive smartphones we have) can be common depending on the areas you are visiting. Have a remote wiping application enabled on your phone. I wouldn't put too much hope in the tracking feature as some countries do not have resources to "track down the phone of a tourist" they might have bigger fish to fry.
Get the correct plug adapter (whatplug.info shows G,D & M)) and do not charge from USB stations like you may do in American airports.
Turn on two factor authentication methods for email and banking during your trip. You could have these warnings forwarded to a service like Google Voice (free).
Keep Wi-Fi and cell service off (airplane mode) when not using it to avoid connections.

A more thorough checklist is provided here by and article in Security Magazine. This list may seem like overkill but depending on your job and the type of data you carry (read: the stakeholders of that data) they may be more essential.

Have a great trip!


How to make secure communication between servers I have two servers with 2 web application in PHP, I need this server make a secure communication there is my scope:

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.

Which is the best way to figure it?

I was thinking on some alternatives like a hash key and encrypt the information making a window of 1 minute to that information be valid, so if I get a post with a date with more than 1 minute of the actual date it's a invalid post.

My biggest worrie is Man In The Middle attack.

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.


At which point can a system be compromised when downloading archived data from an untrusted source? If I download archived data from a possibly untrusted source at which point am I at possible risk of harming my system:

Initially downloading and saving the archived data (still packed)
Unpacking the archived data
Executing any file from the unpacked archive

At point 3 I will obviously be at risk, but what about 1-2?

1 should not present any danger as long as the file is just saved somewhere and no attempts to open it with anything are made. If you view it even with a text editor, there's already a small danger of exploits.

In the case of 2 there are vulnerabilities and exploits, so there are dangers. Some examples of such possible scenarios:

Arbitrary file writes caused by .tar.gz archive symbolic link (symlink) vulnerabilities that are exploited because of how Bower (a popular web package manager) extracts such archives
CVE-2018-20250 is an absolute path traversal vulnerability in unacev2.dll, the DLL file used by WinRAR to parse ACE archives that has not been updated since 2005. A specially crafted ACE archive can exploit this vulnerability to extract a file to an arbitrary path and bypass the actual destination folder. In its example, CPR is able to extract a malicious file into the Windows Startup folder.
CVE-2018-20252 and CVE-2018-20253 are out-of-bounds write vulnerabilities during the parsing of crafted archive formats. Successful exploitation of these CVEs could lead to arbitrary code execution.
Zip Slip which attackers might use to target files they can execute remotely, such as parts of a website, or files that a computer or user are likely to run anyway, like popular applications or system files.
Helm Chart Archive File Unpacking Path Traversal Vulnerability.
CVE-2015-5663 - the file-execution functionality in WinRAR before 5.30 beta 5 allows local users to gain privileges via a Trojan horse file with a name similar to an extension-less filename that was selected by the user.
CVE-2005-3262 allows remote attackers to execute arbitrary code via format string specifiers in a UUE/XXE file, which are not properly handled when WinRAR displays diagnostic errors related to an invalid filename

There are plenty more examples and databases with such vulnerabilities and even most of them got fixed in later versions of the software, a risk still exists.

So therefore, [2] is risky and should be handled with care.


What ways can you monitor all changes made on a Linux server? Sometimes we have contract developers that need to do work on the server (via ssh or sftp) and I've been looking for ways to monitor what they do on our Debian based server. We have ways of limiting access (restricting access by IP) so they only have access when we have them working on something but we would like to be able to monitor sessions in a way that we can see what they did (possible on desktop but I'm not sure if this is possible on a Linux server).

Sometimes contractors need privileged access to troubleshoot problems which may mean they can change nginx configs or modify databases. Privileged access also gives them the ability to add malicious code (logic bombs, etc) or break stuff by accident without knowing what they did to break it.

LXD isn't a good enough option because it doesn't monitor key entries and the resources contractors need access to (entire php web application stack) is the asset. So if they break it, we have to switch to a backup web server anyway. While chroot can be used to limit what the user can do, it's not a monitoring tool.

The history file in Linux can be modified by the user and even if it couldn't be modified, it doesn't show commands run after entering a prompt (like after entering mysql or opening a file). Adding git to the root of the system has the same limitations.

We have a server that has the production database and native scripts for the website that we can quickly switch to in an emergency. But without a way to inventory who's had access AND exactly what they have done, tracing blame or even defining what was done is a nightmare.

Options I've Looked at:

This option acts as an authorized MIM and records ssh
session info on a proxy server. This is very similar to what I was
saying would be ideal in my comments. I haven't tested this yet.
Similar option by ezeelogin but like the above option, i don't see a way to manage file changes over sftp so i'll have to test to find out if this is supported.

What solutions are available for this?
Are there any reliable key-loggers that can be used for this?
Are there any enterprise solutions for this?

Two different approaches could be used.

File integrity monitoring.

Host based intrusion detection software such as AIDE can be configured to record hashes of important files on the system and then perform periodic scans to report on files that have changed.  In your case, if the contractors sometimes have root access, some steps would need to be taken to ensure they could not modify the hashes to avoid changes being detected.

Audit logging

The Linux auditd Daemon can be configured to log all commands run by an administrator.  As described in this question;
In https://serverfault.com/questions/470755/log-all-commands-run-by-admins-on-production-servers

In this case it would be wise to use syslog to send the logs to a remote server that the contractors do not have access to in order to prevent them tampering with the logs.


How Risky is Paribus? Paribus (https://paribus.co/) is a service that automatically gets money back for you if there's a price drop on a product you purchased.

It seems to work by monitoring your email, to which you must give it read / write access to.  Yup, that's the risky part.

They say impressive-sounding things on their FAQ page (https://paribus.co/faq) like "tokens" and "TLS".  And they do offer a perhaps slightly less-risky suggestion to create a separate email account just for online purchases.

Their service is free - they take 25% of any savings they can get for you.

But I wonder if it's worth the obvious risk (and maybe less obvious problems) of allowing a 3rd party service into my email.

Thoughts?

Looking at it from a security point, I wouldn't recommend it. You're giving someone else the rights of your e-mail, they are basically you from that point.

And just like @AstroDan said they are gathering information about your buying habits. It makes it easier for you, but someone else is making much more money of it.


IDS in combination with vulnerability scanner I'm planning to set up a server environment with high security requirements on which i want to install an intrusion detection system (snort). Additionally, I think of running a vulnerability scanner (OpenVAS)
on a regular basis (nightly). My concerns are whether
a) wouldn't this render my ids reports during the scan useless and if so,
b) what can i do to prevent this?
I thought of disabling the ids during vulnerability scans, but i believe an intelligent attacker could
see these times as the perfect moments for undetected scanning on his own/attacking.

You've got a number of options.

The first and most common is to instruct the IDS to ignore attacks originating at the vulnerability scanner, and to configure the vulnerability scanner to correspond to the IDS.

The second solution, which requires a lot more work, but has a lot more value is to take this as an opportunity to validate the behavior of both tools and the network.  If you analyze the behavior of the vulnerability scanner and the IDS, you should be able to make a fairly precise prediction about the behavior of the IDS in response to the vulnerability scanner.  Configure your IDS to record the predicted events and to screen them from reporting, or set them to a very low priority.  For example, "I expect to see a port scan from IP Y between timestamp T1 and T2 every night that hits ports P1,p2", etc."  That confirms that both security tools are working, and should radically increase your confidence that your network has not been penetrated. (An adversary is going to want to disable your IDS and your vuln scanner; the adversary is very unlikely to do so in a way that will match your predictions). If your adversary is that good, you didn't have a chance in the first place.

Somewhere I have a information assurance/risk management/security management model. As your security practice becomes more and more sophisticated it should enable you to make better and better predictions about your network/environment.

And remember Wallace's first law of network security; if you don't effectively manage your network, your adversary will be happy to do so.


Should I allow http script sources in my CSP, or enforce https only? I'm currently trying to implement a third-party widget into my website. That widget attempts to load some scripts over http, which is currently disallowed by my content security policy.

I'm concerned that setting the CSP to allow a script loaded over http would enable a man in the middle attack. The offending widget is on the login page, among other places, so an injected malicious script could easily steal someone's password.

Practically speaking, how concerned should I be about this? Should I enforce https-only script-src in my CSP?

You are completely correct that loading just one script over HTTP means walkover to a MITM. So what can you do?

If the script is served over HTTPS
As Ajedi32 suggests in comments: If the script is served over HTTPS, you can force the widget to use HTTPS by using the CSP upgrade-insecure-requests directive.

If you have control over the script tag
If the script isn't served over HTTPS at all, things will be a bit more complicated. You don't have to allow all scripts to be loaded over HTTPS, you can just allow that one. Still, for a MITM that would be enough.

If you have control over the script tag where the script is included, you can use subresource integrity to stop a MITM. You provide a hash of the script in the integrity attribute of the script tag. The browser verifies the hash, thereby stopping any attempts by a MITM to modify the script. It will also give you a headache if the maintainers of the script changes the content without notifying you first...

Else
You are out of luck. Contact whoever constructed the widget and tell them to use HTTPS. Or just dump the widget.


Techniques for fingerprinting a web based content management system (CMS) Let's say we have a random basic blog or informational website: just some pages with information, a sidebar with an overview of the archives, the normal stuff. We know of this website that it's built with a CMS. How can we get to know which CMS built this website?

So I'm looking for basic, general typicals of several much-used CMSs, so that we can get to know the working power behind any informational website or blog.

For example, a typical might be that WordPress adds such a line to the HTML:

<meta name="generator" content="WordPress 3.5.1" />

It sounds like you are interested in finger printing a CMS. This can be done similar to what is done with nmap. You would need to compromise a library of unique urls, etc and than scan a page to see if they exhibit these.

You can use BuiltWith.com.

Here are some examples of it is use:

Joomla.org being positively identified as Joomla
Wordpress.org being positively identified as Wordpress

Some other useful/related finds:

Nmap Plugin to identify Drupal websites
Scritch seems to have a script similar to BuiltWith
Wapalyzer Plugin to do some detections
web-sorrow: a perl based scanner which includes checks for CMS
Blind Elephant: another scanner
plecost: A wordpress specific scanner
whatweb: yet another scanner which doesn't seem to be as actively developed
OWASP Favicon DB: Not quite functional on its own, but if you hash the favicons as you download and they match, could be used as one indicator.

You could also do some google hacking with the url + keywords like "Joomla" or "Wordpress" to see if the site is listed in a showcase, they asked for help on a forum for a particular CMS and listed their site, comments, code hints, search for specific strings in the url, e.g., inurl:index.php?option=com_content.


Bluetooth Pairing Security I'm building an application which must securely transfer data between a mobile device and a BLE peripheral.

I've been reading up on the different pairing methods and the level of security offered across BLE 4.0 to 4.2. It seems as though the process used for pairing pre-4.2 is insecure to passive eavesdropping by design.

So my question is quite simple: what device has to have what version of BLE for this process to be secure? The central, peripheral, or both?

In any kind of encrypted communication, both endpoints must support the encryption.

So, to answer your question, all the devices must support the encryption.

Normal bluetooth cannot be passively sniffed, so I recommend using normal bluetooth.


At which point does an exploit against TAILS happen? Since TAILS by default disallows root/superuser privileges and since traffic is sent encrypted with each relay removing a layer until the exit node, at what point is an exploit on a version of TAILS with known vulnerabilities happen?

A typical sequence is remote code execution exploit followed by sandbox escape and privilege escalation.

First, the attacker would have to be able to run code inside Tails. This is possible through remote code execution if there is a vulnerability in Tails which allows this:

Exploiting a vulnerability in a browser or libraries using it can be exploited if the user visits a website exploiting this vulnerability. It is exploited by triggering the browser into downloading and viewing (image/media) or executing (javascript) the crafted exploit, which allows the attacker to execute arbitrary code on your machine by triggering a known vulnerability. There are many possibilities - vulnerabilities in image parsers, in Javascript engine, in HTML parser, in various audio or video formats, and so on.
Exploiting a vulnerability in other networking components used by Tails (such as NTP client which is used for time synchronization). An attacker who learns about the vulnerability in the NTP client, and can gain control over the relevant NTP server, can trigger this vulnerability remotely and without any user interaction. Same for exploiting a vulnerability in Tor client itself.

Once the attacker gained code execution on a system (even under limited privileges and without superuser), the attacker can attempt try to use  other type of exploits, such as privilege escalation exploits, to gain privileges in the system. And depending on attacker's goal it might not even be necessary to gain privileges.

So, as you see, exploits can happen at many points, and are not limited to a single point.


How to compare passwords with duplicate password On Steam, the gaming client, I have this habit of creating multiple "smurf" accounts.

I have a randomly-generated, unique password, and I decided to use the same password for all of my multiple accounts. On my fifth account or so, Steam has started preventing me from using the same password again.

How does Steam know whether a password has been used before without compromising my security?

This is bad.

They're either storing the password:
* in unsalted form (which is bad),
* in reversibly encrypted form, from which they can reproduce the plaintext (this is worse),
* in unencrypted form (this is the worst).

The prefered way to store passwords is in salted form. This is explicitly made to prevent identical plaintexts winding up as identical ciphertexts. So they can't be using salts.


How can I get EAPOL packet's number? I need to work with EAPOL packets, and I have to distinguish between first, second, third and fourth...

If I'm using WPA2 I can use the first 2 bytes of Key Information field, and I can use Key MIC, Secure, Encrypted Kedy Data... But if I'm using WPA I can't use them because are always settled as zero...

So, have you any suggestion to me??

I solve it for both WPA and WPA2 using MIC_SET, ACK and NONCE fields.

MIC_SET   |   ACK   |   NONCE   |   Packet Number
   0      |    1    |     x     |        1
   1      |    0    |     x     |        2
   1      |    1    |     x     |        3
   1      |    0    |     0     |        4

Where with x I indicate that the NONCE has a value different of 0000000...


How safe is my login system (conceptually)? I implemented a 2FA authentication for a web app with PHP and Google Authenticator. In order to login to my system there are a few steps:

User types in a complex master password in order to access the login page. The request is throttled for only 1 request every hour and includes a CAPTCHA.
User types in username and password in a web application on their computer. Forms contain CSRF token.
There is a Google Recaptcha V3 to ensure the request comes from a human. This check is done in the front and backend.
When the username and password matches, the server gets the secret key from the user database table and generates a QR code which is injected as a data URI src inside an HTML image tag. The user scans the bar code with google authenticator, which in turn generates a code which the user can use to login to the system.

What I don't understand:
Can't anyone scan the QR-Code if they cracked the username and password?
I have the feeling I'm doing something wrong in step 4.

Anyone could download the authenticator so I'm not entirely sure if its secure or is storing the secret inside my database a bad idea? Should users type in their secret to generate the QR code manually? Also, I'm thinking, shouldn't the secret change every once a while?

Using a QR code in the process you described basically just ensures that the user has a cell phone, if I understand it right. So, yes, your suspicion is correct.

The way that apps like Google Authenticator are used is that the QR code is generated one time, when the account is set up (or when the user chooses to enable 2FA). The QR code is a way of sharing a secret between an app on your phone and the backend server. Once the secret has been shared with the app, the QR code is not used again (unless you need to register another app with the 2FA system and keep both apps active).

From that point on, Google Authenticator will continually generate a new temporary code every minute based on that secret. The login process will present an entry point for the temporary code. When you enter a temporary code (during the time when it is valid), it proves that you have a device that knows the secret.

While we're at it, step one is a little goofy also. For starters, I'm not sure how you would rate-limit attempts. Would you do it based on IP address? One IP address can have many users. It would be annoying if I couldn't login for the next hour because my roommate just logged in.

Beyond that, it adds one more password. A passphrase is the same factor as a password. It adds security, a little bit, but is it enough to justify memorizing something else? Why not require the password to be longer instead?


In what ways can the contents of RAM be (inadvertently) written to disk? I'm working on improving the security of my own system by mitigating the chance sensitive information, (e.g. encryption keys) stored in RAM, are inadvertently written to disk. As of now I know of three common ways this can occur and how they could be mitigated:

The contents of RAM are copied to hiberfil.sys when Windows Hibernates

Solution: Disable Windows Hibernation

Some contents of RAM are copied into the swap file.

Solution: Encrypt the swap file.

Memory Dumps during Windows Blue-screens.

Solution: Disable memory dump file generation

Excluding these (as well as tools specifically designed to dump memory) are there any other reasons RAM could unintentionally be written to disk by the operating system?

I would really appreciate any help I could get!

Program crashes save minidumps that contain some parts of the process memory, including thread contexts, some active pages, the stack, etc.

The solution for all of these, though, is to use full-disk encryption (FDE). That way it doesn't matter what data is written to the disk - memory dumps, logs, cached files, etc. - they're all encrypted at rest anyway.

If you've got particularly sensitive operations that must never touch disk, the usual way to go is to have a read-only storage medium and boot from that. Unfortunately, Windows doesn't like that and generally will not boot without a writable root NTFS volume. Instead what you can do is build a machine with sufficient RAM to install Windows to a RAMdisk, perform whatever volatile operations you need to, then unmount the RAMdisk and all the contents are permanently lost. RAMdisk tools can also use AWE to force memory to be marked as physical-only, so it can never be paged out to the swap on the host system. You only need about 48GB of RAM to do this, although 64GB gives you a bit more headroom for mounting a ~32GB volume and running the base OS and guest VM.


Is it possible to encrypt portions of a file for upload so that one does not need to encrypt the entire file first? Normally, to upload an encrypted file I would first encrypt the entire file, then upload the encrypted file. However, for large files this is not that easy as I need a external hard drive to hold the encrypted file. I am wondering if it is possible to perhaps encrypt a large file, say of 500 GB size, bit by bit, and to send the bit by bit encrypted information to an upload stream to say, Google Drive? Thanks.

Yes. Your main problem would be that you will need a client that allows receiving the file from a stream, not as a single file.

For instance, if you were copying the file through ssh, you would normally¹ do something like

  scp myfile.txt remotehost:

However, this expect the prior file to exist. But it so happens that this would be equivalent² to:

  cat myfile.txt | ssh remotehost 'cat > myfile.txt'

which is a form where you can now easily insert an encryption filter

  cat myfile.txt | gpg -e -r AA00BB00CC00DD | ssh remotehost 'cat > myfile.txt.gpg'

Another alternative would be to use a virtual filesystem that showed the files as encrypted, but perform the encryption on access. This would make the encryption layer transparent to the programs that perform the upload.

An example of this would be the encfs utility, that uses a FUSE filesystem. The man page itself shows an example of using it with the --reverse flag in order to create an encrypted view for copying the files.

Finally, a last method to not need the double disk space, would be to encrypt the file over the plaintext one. That is, use a program that encrypts the first 10MB³ of the file and replaces the first 10MB of the original file with the encrypted ones. Then the second chunk of 10MB and so on.

This bears the risk however that if the process failed mid-way (such as due to a power loss), you would get a half-crypted file. And if you wanted to keep the file decrypted, you would need to perform a second pass inline decrypting the file after the upload. I would only recommend it if you wanted to leave the local file encrypted but you have no space to process it differently. It still solves your problem, though,

' I would consider the most common cli commands to be scp, sftp and rsync, all of them presenting the same issue.

² For normal files, not taking metadata into account

³ Or any other arbitrary chunk size

Update: OP comment asks whether it would be possible to break the file in different parts, encrypting and uploading them separately., which is obviously possible. You only need to go in turn extracting pieces of the file, encrypting and uploading them.

The following script would just do that:

#!/bin/bash
FILENAME=file.dat  # File to encrypt, set to "$1" if using as a command
KEY=user321627  # Identifier of the PGP key to use
BLOCKSIZE=$((10 * 1024 * 1024))  # Use 10 MB chunks
FILESIZE=$(stat -c %s "$FILENAME")
BLOCKS=$(( ($FILESIZE - 1 ) / $BLOCKSIZE + 1))
for i in $(seq 1 $BLOCKS); do
    echo Encrypting part $i of $BLOCKS
    dd if="$FILENAME" bs=$BLOCKSIZE skip=$(($i - 1)) count=1 |       gpg -e -r $KEY > "$FILENAME.$i.gpg"
    sha256sum "$FILENAME.$i.gpg" >> hashes.txt
    echo Uploading part $i
    upload-file "$FILENAME.$i.gpg"
    rm "$FILENAME.$i.gpg"
done

Adjust as needed. I am assuming that encryption is done with gpg to an OpenPGP key (generally a good choice), and that there is a command upload-file that sends the file passed as parameter to your final destination, such as Google Drive.

Given that you probably also want integrity in addition of confidentiality, I am storing a hash of each encrypted part on hashes.txt so that you can later verify each piece.


How secure is Keychain on OS X? Keychain is a built-in app on OS X that stores all of the user credentials, and allows for one to keep encrypted notes in an easily accessible way.

Does anyone know how secure Keychain is?  I know there was a vulnerability in 2008 with clear text being stored in memory, but it was patched.  How resistant can it be to cold-boot attacks?

Here are some relevant SE links:

how-do-you-keep-track-of-all-your-passwords - SU
what-is-your-favorite-password-storage-tool - SU
retrieving-osx-keychain-passwords - IT Security - covers brute-forcing (aes is mentioned)

I think this is important since apps written for OS X are starting to store all passwords in the user's Keychain: safari, chrome, subversion, Mail, etc.

The cold boot attack can be limited by setting an EFI password, so that the attacker can't get to the memory during the limited time window following a reset. Notice that if the firmware password is set, the FireWire device driver disallows DMA requests which is another very similar (and IMO more likely) attack.

The key place where the password should be considered "at risk" from any direct memory access attack including cold boot is not in securityd, which does a pretty good job (all of the relevant code is open source so check for yourself), it's in the client application. It's the client application that wants the password, and the vendor may not have been careful about zeroing the memory out (particularly if the password is put into an autoreleased or garbage-collected NSString instance).

(I wrote a whole chapter on Keychain security in Professional Cocoa Application Security)


Server to server encryption: Key rotation over the air. Can it improve security? In my other question, I explored whether to write my own encryption or use an existing one. I was advised to use TLS or AES or something that is established.

This question is about key rotation. It seems that given enough resources, an eavesdropper might could decrypt information, but by the time he arrived at the decrypted product, it would be pretty old. But then he has the key.

The obvious mitigation against that is to change the keys periodically, but it may not be practical to physically bring data to the location to create the new key.

However, if the data was constantly acting as adjustments to the key, or if there were periodic fresh keys sent through the encrypted connection, the attacker would likely have to store lots of data before he finished decryption, then would have to re-play that data to arrive at up-to-date information.

What are your thoughts on this, And are there encryption routines already out there that use either data adjusting the key or automatic fresh key transmission?

With a proper TLS-with-AES session, the time needed for an eavesdropper to "decrypt information" would range in centuries, at least if the "enough resources" are limited to, say, converting the whole mass of Jupiter into energy. At that time I am pretty sure that the involved computers will have turned into a compact mass of rust, so the point is kinda moot. In a nutshell, symmetric encryption is not the weak point of TLS; arguably, properly used encryption has not been the weak point of anything in the last two decades (at least).

Nevertheless, for the truly paranoid who wants to get a warm fuzzy feeling of safety out of ritual cryptographic incantations, you can just negotiate a new handshake over an existing session, at any time you want. Both client and server can initiate that. See the TLS standard, especially sections 7.4.1.1 and 7.4.1.2.


Should I wait until Spectre and Meltdown is fixed in hardware? I have a Laptop that needs replacing due to age.

I will be using this laptop for desktop use, including Office Apps, Development, Running VMs & Web Browsing.  I will be using separation using Qubes/Xen, KVM or Virtualbox.  Note: Laptop won't be running Windows on baremetal (may run as VM), it will run Linux or Xen/Qubes.

Should I wait until Spectre and Meltdown are fixed in hardware* or can current processors be fixed by software updates (for browser and visualization) and microcode updates?

Also please feel free to speculate (no pun intended) when laptop processors with Spectre & Meltdown fixed are expected to be released.

*- all CVEs including  original 3 CVEs, 2 newer CVEs and the expected newer 8? CVEs.

I'd personally say, buy the new laptop if you need to replace. I see multiple vendors offering protection at their own respective layers. From OEMs who provide BIOS / UEFI layer. Microsoft / others at OS layer (https://support.microsoft.com/en-in/help/4073757/protect-your-windows-devices-against-spectre-meltdown) and even browsers such as Google Chrome have started offering protection mechanisms. (https://threatpost.com/google-patches-34-browser-bugs-in-chrome-67-adds-spectre-fixes/132370/)

All in all while the vulnerability itself cannot be fully remediated at software / drivers / firmware level (although intel can  theoretically take care  of this at firmware but we'd all have to bear a performance brunt of upto ~30%>. Combination of patches make exploitation difficult unless you're targeted by extremely potent and determined attacker.

True fix lies at hardware level and intel has not given any updates on when it plans to do this. Although I found the following

There's a possibility, however, that it won't be Skylake-X at all, but rather Cascade Lake-X. Cascade Lake is an incremental revision to the Skylake-SP/X platform: it adds some extra AVX512 instructions, it should include hardware fixes for Spectre and Meltdown attacks, and it should support faster memory

https://arstechnica.com/gadgets/2018/06/intel-is-launching-a-28-core-enthusiast-chip-but-probably-not-at-5ghz/

Enjoy the new laptop. :)


Port forwarding and port blocking security concerns I am highly concerned about RDP security and about multiple occasions of ransomware infections through RDP, so now I am inspecting possibilities for self-defense against these threats.
What interests me a lot is securing of router ports from outside. As it was thoroughly explained here, blocked/filtered port is better than just port having no services bind to it, 'cause blocked port doesn't send response to attacker.

However, what if the port is not blocked , but not forwarded anywhere on router level? Is it equivalent to blocking in sense of security?

In my understanding, unforwarded port is just simply redirected to nowhere, and attacker just cannot use it to compromise anything. Does this makes any sense?

UPDATE: Added reference links for @ISMSDEV and others who don't believe that ransomware and RDP are following in toe.
1. Ransomware and RDP – Are you vulnerable?
2. Ransomware spreads through weak remote desktop credentials
3. Ransomware using Remote Desktop to spread itself

Let me make a few assumptions to try to simplify this:

You're talking about a home or SOHO network, and not an enterprise environment.
Your router performs Network Address Translation (NAT), hence the need for port forwarding.
You're interested in explicitly blocked traffic vs a lack of forwarding.

So let's compare what happens in each case.  For the case where you have explicitly told your router to drop incoming traffic on port 3389:

A TCP SYN packet comes in with destination IP set to your router and destination port 3389.
Your router consults pf/iptables/whatever vxworks uses and determines the packet should be dropped.
The packet is dropped, the router forgets about it, and no response is sent to the attacker.

For the case where you just have nothing forwarded:

A TCP SYN packet comes in with destination IP set to your router and destination port 3389.
Your router consults pf/iptables/whatever and finds no explicit direction to handle it. (Including no port forwarding!)
Your router consults its network state table, finds no matching connection (either established or "related"), so the packet does not need to be forwarded on via NAT.
Your router checks for a listening service on port 3389 itself.
Since 2/3/4 struck out, the router has no idea what this packet is supposed to do, so it sends a connection reset (TCP RST) back to the requesting host.

In either case, no TCP connection is actually established.  Some people believe that dropping packets is better because it "hides your presence" online.  I guess that's potentially true, but then you need to drop on every port and have no port forwarding.  Otherwise, it's clear to an attacker that your IP is alive.  Furthermore, most SOHO users should be most concerned about opportunistic attacks rather than targeted -- in that case, attackers will just be scanning large blocks of IPs looking for port 3389 open.  Dropping a packet or resetting makes little difference to this attacker.


Application Security of crypto keys Is there a way to secure a byte[], PrivateKey, PublicKey, KeyPair, and SecretKey in an application so that a malware would be unable to retrieve the key by analysing the memory? Or at least, how to harden it so that it is more difficult to retrieve the ephemeral keys (no "protection" using hard-coded keys please)?

Or is it pretty much a "goner" if the attacker has access to the device?

Language is Java, so please assume that the attacker has full knowledge of the source code.

Without using HSMs and other similar devices.

You can't protect  against your host, be it the OS, the processor or the BIOS.
Also see the Laws #1 and #2 of Security.

This doesn't mean though, that there's no way to defend yourself against at least some software attacks. Please note though: If you really want to protect the key, you have to use hardware-enforced technologies like HSMs, TPMs, smart cards and SGX. The first two methods I'll outline are basic and are done by every somewhat decent cryptographic library, the latter ones are more exotic.
Defense #1: Always clean up behind yourself!
It is generally considered best practice to always clean up whatever mess you create in programs. This also applies to security engineering and thereby you really should reliably zero out every key when you don't need it anylonger. Note that a simple C-style memset(pointer,0,size); won't do the trick because the compiler most certainly will optimize this away, you should use dedicated functions for burning your keys in memory (Windows offers them and you can write them yourself - in assembler or as a simple loop).
Defense #2: Never stop watching your keys!
Modern operating systems commonly ship with a feature called "swap-memory", which is great for the application developers as this can increase the size of the RAM when needed by swapping out pages to the hard drive. This however is really bad for security, because wiping the keys after they have been swapped out tends to be rather difficult and thereby you should tell your OS through an appropriate function call to always keep your keys in (physical and ephemeral) RAM.

The following defenses are more advanced and it is less likely they are deployed anywhere. They are however listed in Schneier's Cryptography Engineering and can defend you in some circumstances. Let the tinfoil hattery begin!
Defense #3: Encrypt all the things!
You may have heard about "cold-boot attacks". Basically they are the (unlikely) scenario, that an attacker can get hands on your machine, cool it down (more or less) and extract the secret cryptographic keys for several seconds or even hours. It is very hard to defend against such attacks (which also include (automatic) memory dumps). This is why the Boojum (this is the actual name!) was invented.
Say, you have secret keys k,l,m,n, each of length 128-bit. Now you create another secret key i, which you use to AES-encrypt k,l,m,n in CTR or GCM mode (authentication doesn't matter too much here). Now whenever you need k,l,m,n, you just AES-decrypt it and use it and re-encrypt it or wipe the temporary copy. The question now becomes "How to protect i?" With the Boojum, you create a random string R in RAM at a physically distant memory location than i. You hash R and XOR it with i and store that. Whenever you need i, you hash R again and XOR it with the stored value to recover it. Of course this isn't too secure if you keep R the same all the time, because the RAM will eventually "learn" the value and keep it longer, so you need to update this often. You update it, by (optionally) selecting  a new memory location and generating a new R' and storing R' XOR R at the (new) location in memory. Now you unmask i using R's hash and hash the "new" R and mask i again. Of course you delete the old R. It is recommended to repeat this update process frequently, e.g. every second.


Plausibility of DNA sequence for encryption To start with: This is in consideration of in-body implants.

The answer should (initially) assume there is no record of your DNA sequence mapped by a third party yet.

The question boils down to using your own DNA sequence as private key for communication to hypothetical in-body augmentations/devices.

Edit: Further clarification: The device would only be controlled from outside the body, not automation etc. A laptop or (god help us) and 'app' for example could send it commands.

A DNA Sequence as we understand it, is unique to each person.

Is this already possible, is it even a worthwhile investigation if not, and what might be the areas to focus concern.

DNA Sequencing

Interesting related article

Edit: I should add the reason for posing the question is that it may be a field we as humans move towards, and the biggest drawback I see is the concern of data protection and security around it.

A major problem with modern biometric authentication is the fact that it uses things like your fingerprint as a password. Unlike a real password, a fingerprint is not sufficiently secret. Biometric identities can be used for usernames, which merely need to be unique to you, but not passwords. There are a few issues with using DNA as a private key or any other secret value:

You leave exact copies of your DNA on everything you touch.
The human genome does not vary much, making brute force a risk.
People who you are related to have an even more similar genome.
DNA actually changes over time in an individual, so it is not static.
You cannot revoke your DNA and change it after compromise.

You leave your DNA everywhere
A good private key or password is something you know, something which you need to voluntarily reveal. "Private key" implies that the key must remain secret and its knowledge allows someone to identify as the original holder. Unlike a password-encrypted private key on your laptop, you leave your DNA around everywhere. In your breath, excretions, skin cells that fall off in the millions, oil, hair, saliva, tears, etc. This makes it pointless for a private key that, as the name implies, must remain secret.
From a recent case where DNA was used to incriminate an individual, three judges pointed out the risk to people's privacy when DNA left unintentionally can be used as evidence in a criminal trial. Regardless of the outcome of this review, the fact that we leave DNA is still there:

The Majority’s approval of such police procedure means, in essence, that a person desiring to keep her DNA profile private, must conduct her public affairs in a hermetically sealed hazmat suit. Moreover, the Majority opinion will likely have the consequence that many people will be reluctant to go to the police station to voluntarily provide information about crimes for fear that they, too, will be added to the CODIS database.... Majority's holding means that a person can no longer vote, participate in a jury, or obtain a driver's license, without opening up his genetic material for state collection and codification. Unlike DNA left in the park or a restaurant, these are all instances where the person has identified himself to the government authority.

It doesn't matter if the government decides whether or not this evidence is admissible. What matters is the fact that the evidence, in the form of DNA, is left over in the first place for anyone to take and analyze. Worse still, once your DNA is "compromised", it cannot be revoked!
The (lack of) genetic variation in Humans
Only a tiny fraction of DNA differs between each person. While DNA itself contains a lot of information, any prototypical human genome is going to be extremely close to your genome. If you use your genome for any sort of cryptographic purposes, the differences will be small enough that brute force becomes feasible. In other words, there's just too little difference between us. Not only that, but your family will have an even more similar genome. Even if random genetic variation were great enough to prevent exhaustive search, do you really want it to take nothing more than both your parents to give up their genome to make it possible to "calculate" your genome? Or your siblings?
A large amount of human genetic differences comes from what's called SNPs, or Single Nucleotide Polymorphisms. These are individual bases in DNA which are known to vary between people. Currently, there are only a few hundred million known polymorphisms. While a hundred million may seem huge, people who are ethnically related will have far fewer genetic differences. A good key will differ equally between users, regardless of whether or not they are related by family or race.
Jumping genes (transposable elements)
There's another problem. If you are analyzing DNA down to each individual base pair, you'll find that it actually changes over time! Small self-reproducing elements called transposons are sequences that copy themselves and re-insert themselves in different areas of our genome. They do this slowly and rather randomly. Over time, this means that even our individual cells won't have the same DNA as they had when we were born. Likewise, even identical twins won't have perfectly identical DNA as a result of this phenomenon. This is not a problem for most modern genetic sequencing, which only counts specific variations on specific genes (called alleles), but will be a problem for anything that requires exact accuracy down to the individual base pair. 40% of DNA is transposable!
DNA as a unique identifier
Now, what could your genome be used for? Identification and authentication. While it's very easy to discover your DNA sequence, it's quite impossible to copy it into another person's body. No matter how much I try, if a single cell of mine is extracted and its DNA analyzed, it will show the DNA I had at birth (ignoring jumping genes), not your DNA. This makes it possible to prove an individual is who they say they are, given sufficiently careful DNA examination. It's like a SSN, but much, much more difficult to use for identity theft. Knowledge of your DNA doesn't let you impersonate it.
DNA is not the only thing that can be used for identification. The pattern of veins in your hand are unique to you, and unlike fingerprints or DNA, are not left all over everything you come into contact with. You need to explicitly place your hand on a vascular scanning device, which is less intrusive than a retina scan. This is actually a technique that is used in Japan. While this is still more private than DNA, it is still better used as a username than as a password, since it can still be obtained surreptitiously.


Initialization vector with cipher block Is the initialization vector used to encrypt a block of data always static or dynamic? If it is dynamic then I should send the IV along with the key to the recipient right? This normally doesn't happen.

In block cipher algorithms the IV is not secret. Only the key is secret. Most of the time an IV is just a block of random data and is sent along with the enciphered message to the recipient. Actually the IV can be considered as an algorithm parameter.


Can a website download documents, images, or other information onto my iMac without my consent or awareness? I've heard that websites that download malicious data onto the user's computer without their consent do exist, but is this possible on an iMac as well as Windows and other operating systems? How about iPhones?

Basically, can websites download content onto your Apple device without your consent? I've heard that Apple devices are much more secure than Windows and Android and that they aren't as widely targeted.

In certain cases, yes it can, what it is usually called is a "drive by download": JavaScript exploits, Java exploits (or even you approving the download), and other exploits can indeed infect your computer, if you believe a website is risky you can download the NoScript extension or disable active plugins like Java or JavaScript entirely.

But please know that attacks where a malicious website can download malware onto your computer without your input [downloading a file. approving a prompt, etc], are very rare and will require a zero day exploit which is very expensive.
This is why you are often asked to keep your software up to date, because any exploit found in a certain version can only be fixed in a later version, it isn't going anywhere.


Does Wanna Cry encrypt files on network drives? I've dealt with ransomware threats in the past, such as LOCKY that not only encrypt data it considers user documents found on the local machine, but also on any network drive to which the user has sufficient permissions to change data.

Do any of the Wanna Cry variants enumerate and encrypt data on:

Mapped network drives?
Network shares that are not currently connected via a mapped drive?

I've Googled my question but not found a direct answer.

Note: I'm not asking about how the Wanna Cry threat infects other nodes via the EternalBlue SMB exploit.

Yes, WannaCry will target network drives and removable media, according to Talos Intelligence:

  The file tasksche.exe [a WannaCry component] checks for disk drives, including network shares and removable storage devices mapped to a letter, such as 'C:/', 'D:/' etc. The malware then checks for files with a file extension as listed in the appendix and encrypts these using 2048-bit RSA encryption.

This is specifically worrisome because according to the technical analysis by Endgame Inc the malware also grants full permissions to Everyone on files which it is capable to do so which could have severe ramifications in the case of Active Directory shares.


Does the stackexchange mobile app use HTTPS? I am curious whether the stackexchange mobile app (specifically on the Apple app store) uses HTTPS protocols, does it?

Is this the same with other apps that access the stackexchange network?

The Stack Exchange network is only accessible over HTTPS. If you try to access it over HTTP, you'll just get a redirect:

% curl --include http://stackoverflow.com/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://stackoverflow.com/
[…]

Additionally, Apple has measures in place to incentivize apps to use HTTPS. Apps are required to explicitly declare which servers they will use HTTP to communicate with, and Apple may reject apps which are not using HTTPS appropriately.


How can we exchange public keys between two servers in a secure way? I have two servers with a pair of RSA public and private keys.

We do not use a CA for the internal communication yet and therefore we need to exchange keys without CA.

I need to establish a trust between two servers: I need to copy a public key form the first server to the second server and the public key from the second server to the first server.

Note that it is not Diffie–Hellman key exchange (that explained very well in "Diffie-Hellman Key Exchange" in plain English).

The simplest way is just manually copy the public keys from one server to another.

An additional option is to use the following homegrown flow:

Generate a one-time token on the first server
Copy the token manually to the second server
The first server accesses the second server via an API. Ase the token for the API authentication. The API implementation exchanges public keys between servers

Any suggestions to improve the flow?

Do we have some best practices flow, since homegrown flows are usually bad for security?

This will mean a lot of unneeded overhead. I'd suggest following:

Since you don't have certificates issued by CA, create your own CA. Namely, create a self-signed certificate and add it to a key store on both servers, so that your certificate is trusted.
Issue certificates to each server and sign them with private key of your own CA.
Make your servers use their certificates when communicating with the others.

Thus you will actually use PKI.

In the future, when you get certificates from the real (commonly known) CAs, the only thing you will need to do will be to replace your own self-signed CA certificate by (also self-signed) certificate of a real CA.


Is there a clipboard timeout? The "clipboard" buffer might contain sensitive information (like passwords, or private messages sent to or received from other people) cut/copied previously, that, wenn accidentally pasted into a wrong window, can leak this sensitive information.

This can very well happen by accident when a users attempts to cut/copy something, and believes that the cut/copy operation succeeded, when it in fact didn't. When pasting the buffer content, it would unintentionally be content from a previous cut/copy operation.

Password managers like KeePass provide a functionality where the clipboard buffer is cleared automatically after a predefined timout, so that passwords cannot be pasted by accident.

Do common desktop operating systems (Windows, Mac OS and Linux) provide a way of configuring such a clipboard timeout globally?

Alternatively, which third party tool provides this functionality?

Sadly as far as know there is no such feature as "clipboard timeout". I miss this too :(.

Actually, the current evolution of end-users desktop environment seems to go the opposite way, with so-called "clipboard managers" enabled by default which store the history of the nth latest clipboard values, thus heavily reducing effectiveness of password managers' clipboard clearing feature (clipboard current value will be cleared, but the password will remain accessible and readable in clear form in the clipboard manager history...).

The only technical workaround I know is to run a system-specific command at regular interval which will clear the current value of the clipboard (command which may not be even available by default, at least on Linux, and therefore require a specific installation). As ugly as it can be, but I did not found anything better.

Otherwise, you have no other choice than train yourself to consider the copy/paste operation as a potentially risky operation and double check what you are doing (and of course get rid of these awful clipboard manager software!).


Reading mail from GMail with secure access I recently implemented PHP code with IMAP for reading mails from a GMail account and further executing some command depending on the mail body. I got this to work after consulting the first answer from this link.

My questions are:

1) What does "allowing access to less secure apps" mean?

2) How do I make it secure?

While there may be other security problems, a big one is that this authentication mechanism bypasses Google's 2-factor authentication. If you go to the  https://www.google.com/settings/security/lesssecureapps page to enable Google 2FA while you have 2FA enabled on your Google account, Google displays this message:

  This setting is not available for accounts with 2-Step Verification enabled. Such accounts require an application-specific password for less secure apps access. Learn more

This is because there is no way for the client application to accept the 2FA input and pass it to Google.

One of the advantages of protocols such as OpenID Connect is that entire authentication workflow is delegated to the authentication provider. So when an OpenID Connect enabled application wants to authenticate, it calls the authentication provider to display the login page. This allows the login workflow to be more complex than a simple username/password.


TLSv1 HandShake but SSLv2 client hello I found this question: SSLv3 HandShake but TLSv1 client hello

However, my situation is opposite: SSLv2 client hello then TLSv1 handshake. Can you please explain this for me? I use Wireshark to capture the connections on my Mac.

UPDATE: Add SSL details picture.

The ClientHello message determines what methods of SSL/TLS are supported by the machine, which can include TLSv1 (encoded as SSLv3.1), so after the ClientHello message the machines determined that TLSv1 would be the protocol to use and started the handshake process for TLS.


How can I hide my mac address when using a public wifi? As a new student of cyber security, I have started to see in real-time how an individual can actually scan and view the mac addresses on a public wifi connection.

How can I hide my mac address when using a public wifi connection? Please I mean aside from not using public wifi at all.

Also, I am very DIY, but I am still unclear how VPNs work. I have skim read about setting it up on one's own server, but not sure how that works in conjunction with using wifi, so any documentation would help. I still have a lot to learn about OpenVPN, SSH Tunnel, RaspianVPNs. I know of them, so just tossing these out as answers would not help. I guess I am looking for a how-to than just use this...okay, but how? Anyway, thanks in advance.

The answer is you can't hide your MAC address completely since it's essential in networking. As per wikipedia:

  MAC addresses are used in the medium access control protocol sublayer of the data link layer.

What you can do though is to spoof your MAC address so you don't "expose" the manufacturer of your computer's network card which is going to help you avoid targeted attacks. Also as @multithr3at3d correctly pointed out, by spoofing you MAC address you also prevent your MAC address from being used to track you.


Is using enctype="multipart/form-data" always a bad idea? If the form doesn't have any file upload, you just use enctype="multipart/form-data" everywhere, is it a bad idea from a security point of view?

Here someone says, in 2007

  Uusing enctype="multipart/form-data"
  creates both a binary and an ascii upload, so there's a doubling of
  the traffic. I'm not aware of any other issues. However, it seems to
  me that allowing binary uploads may create some security concerns.

Apart from sending unnecessary data to the server, how this may be exploited?

Using enctype="multipart/form-data" creates both a binary and an ascii upload

I consider this statement wrong. There is application/x-www-form-urlencoded where the body of the POST request consists of the same string as would be used after ? in the URL if a GET request was used, i.e. like this:

  POST /foo HTTP/1.1
  Content-type: application/x-www-form-urlencoded
  Content-length: ...
  ...
  foo=one&bar=two

And then there is multipart/form-data which is a multipart MIME-message where each part consists of the key name given in the header and the body containing the value:

  POST /foo HTTP/1.1
  Content-type: multipart/form-data; boundary=abcde
  Content-length: ...
  ...
  --abcde
  Content-Disposition: form-data; name=foo

  one
  --abcde
  Content-Disposition: form-data; name=bar

  two
  --abcde--

Each part is only sent once and binary data (like file uploads) are sent only as binary.

  Apart from sending unnecessary data to the server, how this may be exploited?

Both ways can be used with several variations in order to try to bypass web application firewalls (WAF). With application/x-www-form-urlencoded one could for example try to play with URL encoding on unexpected places (like encoding the keys, = or &) in the hope that WAF and and server will interpret data differently. Or can could use duplicate keys etc.

With multipart/form-data one could try some of these variations too. But MIME gives even more possibilities, especially if a library gets used for parsing which gets also used for MIME in mails. In this case one could try to play around with innovative boundaries, duplicate boundaries (where server and WAF might pick a different one), try to use Content-Transfer-Encoding etc. But, a better WAF will simply discard any of these attempts since browsers will not issue such requests.


How to show xss alert box when you are inside function in  tag? For example we have this:

<script type="text/javascript" charset="utf-8">
    $(function () {
        var stranica = "#aXSSinjection point";
        var stranicaContainers = $('div.stabs > div');
        stranicaContainers.hide().filter('#ageneral').show();
        $('div.stabs ul.stranicaNavigation a').click(function () {
            stranicaContainers.hide();
            $('div.stabs ul.stranicaNavigation a').removeClass('selectedstranica');
            $(this).addClass('selectedstranica');
            return false;
        }).filter(stranica).click();
    });
</script>

This page is just an example, got it from pastebin. So now how can I show alert box without using </script>. I always try to close that function and then add alert(0) and then ignore the rest of js with //, but sometimes it works sometimes it doesn't.

Some obvious things to try are:

blah"; alert('xss'); "blah

or

blah"; }); alert('xss'); $(function () { var stranica = "moreblah

This question is probably too narrow for this site.


Secure home WIFI-router? Today most of the home WIFI/Routers are vulnerable from a security perspective, with various backdoors, UPnP issuses and more.

What should I look for when I as a home user want to get a secure solution at decent price?

Do I need to look for enterprise products or should I go for any hardware supporting OpenWrt?

How about PFsense on a PCEngines Alix or APU router? Wifi won't be more secure, as it's the protocol, but pfsense can monitor your network I believe. This is on my list as well, just haven't found the time to do this.

http://www.pcengines.ch/order1.php?c=2


Practical implications of 2014's android SOP vulnerability For a project at university I have done research about all kinds of security issues, especially privacy-related ones, that have come up on mobile OS and applications over the last few years.

One of the most infamous breaches I read about seems to be the same-origin policy (SOP) vulnerability that was discovered in Android's stock browser (AOSP) last year. The more I read about this attack though, the more it seems to me that the media have just greatly exaggerated the severity of this issue, since the actual attack vector seems to be quite small to me - at least from a privacy point of view. To sum up what I have found out:

There is an HTTP header field called 'Cross-Frame-Options' which prevents exactly this kind of attack because you can't even open the page in question within an iframe. Judging from some internet research and practical tests, most web frameworks set this header at least to 'same origin' by default, let alone big privacy-critical pages like social networks, online banking services and so on.
If you MITM'ed the connection and you were able to strip the XFO header, that would imply that the communication between victim and server was unencrypted and you could just steal session cookies or document data directly anyway.
I also had the idea to strip an insecure page of the XFO header, then open it within an iframe (say http://amazon.com), then pass the value of the document.cookie field from JS to the outside, since it could theoretically also contain secure cookies. Turns out, there is the 'httpOnly' property for cookies, which prevents exactly this kind of abuse ...

Now I know that there are probably hundreds of thousands of smaller sites that don't implement all of the above security measures or do it incorrectly, but articles like the one I linked (and dozens of others) clearly state that one could read emails from GMail or hijack Facebook sessions with this vulnerability present. Am I correct in assuming that the journalists who wrote these articles just didn't think the whole thing through, or am I actually missing some critical piece of information?

I haven't studied this specific vulnerability, but from the points you mention I should note:

Cross-Frame-Options is not used too much on websites.
Although this SOP vulnerability is dwarfed by X-Frame-Options, two months before there was another one where it didn't seem to matter. Most outdated phones where you will be able to exploit one of them, most likely the other one will also be exploitable.
I don't trust too much on the specific examples given when journalists explain a vulnerability saying “you could compromise GMail / Facebook / BigSite” they are only providing an example in layman terms of what can be done with a vulnerability like that, mentioning a website everyone will know about and care about their privacy. It is possible that those journalists are aware of those finer details, or that the vulnerability description was already “simplified” when explained to them.


Connected devices to router are hidden I was scanning devices connected to my WiFi with netdiscover
netdiscover -r 192.168.31.0/24

I was unable to find any device. I only get router's IP and MAC address.
It does not show any device even though I have connected 2 PCs and 2 Android phones.
My router is xiaomi 3c router.
Can anybody tell me why devices are not visible?
I can see all devices through the router page but not by a network scanning tool.
[I can see devices when connected to my Android hotspot scanning through netdiscover]

I was facing same issue. Was able to get the connected devices on mobile hotspot but not on a router.
Sometimes netdiscover ARP packets timeout in real networks which is very common, Hence, to increase the number of packets sent for scanning, use the following command:
netdiscover -c 10 -r ip_range -i interface-name

This worked for me.


Using TPM with DMcrypt? Is it possible to use TPM for storage of some private key? It's not a full-disk encryption , I want it to be compatible with existing LUKS, just add another key, and store it in the TPM.

Try tpm-luks [1], which is a script that will assist in storing a new secret both in the TPM's NVRAM and a LUKS key slot.

This should do the trick:

$ tpm-luks -c -d <device>

You can find your LUKS device with:

# blkid -t TYPE=crypto_LUKS

I released tpm-luks very recently, so its only available in git ATM.

[1] https://github.com/shpedoikal/tpm-luks


Web security - use of cookie in https I am taking a web security class and was told by the instructor that most of the websites today use https for authentication and then use a cookie (authentication token) in plain text to keep track of the user.

I wanted to confirm this. For example, when I use Amazon.com, if I logged in before, Amazon shows something relevant to my history. For this they must be using a cookie. But when I click on Account, a https page is opened. If I am looking at my account details, why would Amazon choose to send a cookie (acting as an authentication token) in plain text ? If I can listen over the wire, can't I just steal the cookie and hijack someone's session ?

My hypothesis is that websites like Amazon have multiple cookies, some are for pages that don't need https (like the home page), but still want to keep track of user history; others are for tracking if user authenticated previously (so user doesn't need to type password again), and this type of cookie must always be sent over https.

Can anyone confirm my hypothesis ? (I believe my instructor might not be entirely correct)

This could be achieved in a relatively secure manner with two cookies.

One has the Secure Flag set, and will contain your HTTPS session details and is used through out the checkout process when making a purchase. The Secure Flag ensures that the browser only sends the cookie over connections protected by SSL/TLS (i.e. use the HTTPS protocol).

The other does not have this flag set, and will store the HTTP session details. The session details stored on the server side could be items viewed, or if you have previously logged in it could tie your session up to an account. This is what would be used when the site says Welcome John when you return without logging in.

For this to work, there should be no way of determining the secure session cookie value from the insecure one.

The insecure cookie could be used up to the point of entering the checkout or the account details pages, where a login over HTTPS is then required where the secure session cookie is then set. This would stop a MITM attack from obtaining the cookie, as if an attacker stole the insecure cookie the worst they could do is alter the browsing history of the user, or add/remove things from the basket. If it was implemented in this way it would be assumed the user would check that the basket items copied to their secure session are the ones they actually wanted to order before completing checkout (or that they read their confirmation email and cancel items later).

It is not clear from your question whether your instructor is referring to the sending of plain text cookies carefully using good practise like the above, or as a bad example of how not to do it. If the latter, many websites do in fact only protect certain pages such as login and card details pages with HTTPS, but then go on to use the same authentication or session cookie over HTTP pages too, not realising that this cookie value is sent in the clear and can be read by a suitably placed attacker.


What's the attitude of anti-virus vendors toward ransomware? I was recently asked to look at a Windows computer behaving strangely, and I found a "Your files have been encrypted" ransom note that had been left in several directories. I wasn't able to identify any actual encrypted files, except for one copy of the ransom note that had been encrypted by a different ransomware that left another note.

The ransom note was present in 3 formats: a plain text file, an HTML file, and a shortcut (.url file) pointing to the payment web page.

I was able to read some of the files, but some of them (the second ransomware's note, and the first ransomware's HTML file) disappeared immediately on any attempt to open them. I was then notified by System Center Endpoint Protection that it had identified them and quarantined them. I had to restore them from quarantine and disable its real-time scanning to be able to read them.

This seems to me like a drastic action. It acted as if reading the note was going to cause further damage, when in fact the opposite is true: reading the note is the only way you will ever have a non-zero chance of decrypting your files!

It wasn't just treating them as "generally suspicious" - it specifically said they were Ransom:HTML/Tescrypt.A and Ransom:HTML/Crowti.A so it had enough information to make a better decision.

On the other hand, preventing the victims from reading the ransom notes could be seen as a hard "no negotiation" rule. If victims can't make contact, the crypto-ransom industry will be less profitable, and maybe that fact will deter future incidents, which would be a definite long-term benefit. As for the current victim, well, there was no guarantee the bad guy is really going to give up the decryption key after they get the money...

Is Shoot The Hostage an official policy in the anti-virus industry?

The AV is set to identify and quarantine files associated with malware. It probably can't tell the file is just a ransom note and not something more malicious, so it treats it like it would treat any other part of ransomware.

Also, it didn't prevent you from reading the ransom note entirely, it just made you take a few extra steps to access it. Not quite "Shoot the hostage".