Why are some DLLs not randomized? What makes it hard to deploy full ASLR for all DLLs? One of the challenges with deploying ASLR for everything is that, at least on Windows, some DLLs (libraries) are not compiled in a way that's compatible with ASLR.  (They're not compiled as position-independent code, and so the place where they are loaded in memory cannot be randomized.)

This is problematic, because if an application loads even just one non-randomized DLL, then it is effectively not randomized.  To stop standard attacks (e.g., ROP attacks), all the code has to be randomized: even a single non-randomized DLL is enough of a foothold that ROP attacks can become possible.  So, to a first-order approximation, ASLR is only useful in protecting a particular application if all of its DLLs are randomized.  Applications often load many DLLs, and since all it takes is one non-randomized DLL, this makes it especially important to ensure that all DLLs are randomized.

Generally, the industry is moving towards increased use of randomization, but slowly: I guess it takes time to bring this to every DLL any program will ever use.  For instance, it was recently revealed that the Dropbox DLL does not use randomization, so any program that uses the Dropbox DLL is not protected against ROP attacks (any program that uses the Dropbox DLL loses the benefit of ASLR).

My question: What are the typical reasons why some DLLs are not randomized?  Is it typically some sort of technical barrier or technical issue that makes it difficult or impossible to compile the DLL as position-independent code?  Is it lack of awareness/attention to security, on the part of the developers building the DLL?  Is it legacy DLLs that are very old and haven't been recompiled to take advantage of randomization?  Does Microsoft Visual C++ fail to do the right thing by default (does it fail to compile DLLs as position-independent code by default)?  Is it something else entirely?

Are there any technical advances or tools that would help facilitate greater deployment of ASLR/randomization for DLLs that currently don't support randomization?

Related resources: SlopFinder is a tool to scan your system for DLLs that don't support ASLR.

There is some good information here. Apparently, a DLL can be subject to ASLR only if it is tagged as such, because of "backward compatibility issues". Although a DLL is, by nature, meant to be relocated, I can imagine that some (poorly) written software may do some tricks which rely on the DLL ending up in a relatively small range of the address space (a possible candidate would be some Garbage Collector that needs to distinguish between "pointers to data" and "pointers to code" -- I know that such issues occurred with some versions of Chrome's Javascript interpretor when launched on OpenBSD with Linux emulation).

If Microsoft went to the trouble of implementing an additional flag, then it is plausible, if not probable, that they encountered at least one case of such software that they could not ignore (backward compatibility is very important in the Windows world).

So DLL will allow ASLR to happen if the static linker said so, when the DLL was last built. This is a matter of using the /DYNAMICBASE flag. The documentation states that:

  By default, /DYNAMICBASE is on.

The documentations for Visual Studio 2010 and 2012 contain this sentence, but NOT the documentation for Visual Studio 2008. So one has to assume that most people who use Visual Studio 2010+ produce ASLR-compatible DLL, but most people who use Visual Studio 2008 or a previous version produce DLL which are not subject to ASLR.

In the page I first link above, one of the comments says:

  You can still use the Microsoft linker to do that, after your PE image is built. Use link /edit /dynamicbase (or editbin /dynamicbase ).

So you can "fix" a DLL, but that's assuming that the DLL will not break with ASLR, i.e. the lack of flag was just due to the default configuration of Visual Studio, as used by the DLL vendor.


What are the new security features in Windows 10? Title says it all really.

I realise I can Google this, but the top links don't cover all the new features I am aware of, so people will benefit from a canonical answer here.

I am aware of the following features:

Windows Hello - A new authentication system, which will replace passwords with a combination of biometrics and public key crypto. This will eliminate "pass the hash" attacks. Private keys will be stored on the TPM. Biometric authentication to the local device can use fingerprint or facial scanning. The facial scanning will use a new 3D infra-red technique, which is supposedly greatly improved.

Device Guard - Anti-malware features. This includes a hypervisor, so even if the kernel is compromised, the hypervisor should stay secure. There will also be "mobile like" application segregation.

Enterprise Data Protection - Allows separate data containers in a system, with the ability to restrict apps to certain containers, and features like per-app VPN. Similar to Good Technologies, but integrated with OS.

Windows Update for Business - A new update system, making it easier to keep all systems patched. This includes "deployment rings" allowing you to test patches on a subset of users before full roll-out. Also has peer-to-peer patch downloads.

Just Enough Administration - A mechanism to restrict admin access to the minimum required to do the job.


Are intermediate signing certs the only secure+practical way to manage OpenVPN client certs? My organization needs to issue (and revoke) OpenVPN client certificates for people working remotely.

Our system is based on a standard OpenSSL CA setup and the easy-rsa tools, and the whole directory lives in a git repo that IT team members clone locally on their laptops where they generate and sign VPN certs, and then update the remote repo.

The root CA private key's passphrase is stored separately in a local password management system that is itself protected with a password we don't store anywhere.

Our concern is that anyone who's ever been a member of the IT team and leaves, can easily keep a copy of the root CA private key and its passphrase and can generate and sign valid VPN certs at will even after theirs has been revoked.
Currently, the only way to prevent this is to change the root CA key and re-issue VPN certs to all users (massive pain!)

What's the best practical solution that people use ?

1) Have better procedures and only generate/sign client VPN certs on a single host with a restricted access policy ? This will slow us down significantly in day to day operations and doesn't really prevent an admin to scp the private key somewhere else if they wanted to.

2) Protect the root CA key properly as above, but use intermediate certs for day-to-day VPN certs signing ?
How does this work exactly ? When an IT team member leaves, I understand we can revoke the intermediate cert that's now "compromised" and issue a new one from the root CA, but what happens to the existing VPN certs that have been signed with the previous cert ? What I'm reading about intermediate certs seems to suggest that they remain valid, but I don't understand how.

Thanks!

There are really a few options.  You could try to use a hardware security manager that would lock the key away and only allow signing.  This would prevent any of the IT staff from accessing the key itself, but is a lot more complicated to set up.

You can also (and really should in either case) set up intermediate certificates so that the root isn't compromised by a working key compromise.

You could also implement a cryptographic time-stamping server that has a key that isn't available to IT.  They could then sign as of a given cryptographically verified time and each IT staff member's certificate could be invalidated as of a certain time.  The system could then trust certificates signed by that intermediate key up until a certain point, but not trust later certs or certs that are not time stamped.  This would let you get around having to replace all keys they ever made when they leave.


Can changing your IP address prevent an NMap attack? If an nmap attacker started a port scan on my network, would changing my network IP address prevent/halt it?

Changing IP address is not a good defense strategy. It's merely evasion and security by obscurity.
The only good strategy is a properly configured firewall + minimizing the attack surface, that is exposing as few services as possible.
You are not saying if this is a LAN or a WAN but the deal is not much different really. In practice the IP address range available is limited, so it's trivial for an attacker to scan the whole range and re-discover your assets. You won't remain hidden for too long.
There are things you can do to thwart port scanning attemtps and frustrate attackers though. Have a look at tools like CSF+LFD for example. They will block offenders at firewall level after a certain threshold of port scanning attempts or login failures.
Again, that depends on your circumstances and what you are trying to prevent or protect. Your question should be more focused.
An nmap scan is usually noisy and an IDS should alert you in addition to blocking the attacker. That is precisely what a software IDS such as CSF+LFD does.


Which is more secure - a VPN, a proxy-server, Tor, etc.? And why so, exactly? I want to know how to ensure the most complete anonymity when browsing the internet and connecting to remote servers: I want to be as anonymous and secret as possible. I don't know exactly how VPNs differ from proxies, but are they safer? Is it possible to do a combo: proxy, VPN, Tor, etc.? Will combinations as such make it more difficult to be traced?

For example, a proxy alone isn't completely giving me confidence. But what about a proxy-server, VPN and specialized kernel which has no device information, cookie blocking, concealed MAC address/etc., surf behind Tor and add more proxies to the mix, encryption of sent data, etc.?

Like, on top of circumventing any simple IP, if data is passed anonymously, such as through Cryptabyte behind proxies, Tor, VPN, etc., this makes not only the illegal act hard to pinpoint, but the data which may've been used impossible, correct?

I know I asked multiple questions, but I expect mostly one answer to my main one.

You ask about services, tools and concepts in one question.

All this could be used together, sometime one by another:

You could implement a proxy server to re-routing all you web traffic via Tor, for sample.

I think you have to invest (our time) to ensuring your understanding.

A proxy-server is a tool installed locally or remotely, but installed in one server, to re-serve web pages.
A VPN is a concept that could be implemented by using a lot of different ways (IPSec, OpenVPN, SSH, ...)
Tor is unique, it's an entity (like Facebook, but not with same goal). They use a lot of tools and concepts, like proxy servers and VPN.


Secure CDN content for a multi-tenant application We have a multi-tenanted application that has sensitive content behind a secure login. We'd like to host that content on a CDN but prevent unauthorised users from accessing it.

What are the best ways to do this?

For example, we have the following resource: https://customer-a.example.com/content/video.mp4. We want this served via a CDN however you need to be logged in to customer-a.example.com to see it. How does a CDN prevent anybody from getting the URL and accessing the content?

This really depends on your CDN. Most would minimally check the referrer and some would support single-use or restricted URLs (e.g. only available to a certain IP, time range, etc.).

Check any hot-link prevention documentation of the CDN or ask their technical support for options.

However, for any content, somebody can always download it and reshare it, so if you want maximum protection, you'll have to use some DRM.


What is the difference between host and client ssh key generation? Having read the ssh-keygen man page, i saw the '-h' flag and the following:

  ssh-keygen supports two types of certificates: user and host.  User
  certificates authenticate users to servers, whereas host certificates
  authenticate server hosts to users

I understand the server/client usage, the different storage locations and the certificates are unique, but is there a fundamentally difference?

I.e. If I don't use the '-h' flag during host key generation, have I made an error that could cause issues?

According to the source code of openssh-portable, the -h flag modifies the certificate type and selects permitted options to None.

Here is the relevant source code:

/* Key type when certifying */
static u_int cert_key_type = SSH2_CERT_TYPE_USER; // L105

/* If -h is set, set certificate type to Host and set cert flags to none. */
case 'h': // L2573
    cert_key_type = SSH2_CERT_TYPE_HOST;
    certflags_flags = 0;
    break;

/* Set the certificate type to whatever value was set before */
public->cert->type = cert_key_type; // L1744

As you can see, that's all the magic. If you used the wrong certificate type, then the verifying end will refuse to accept the certificate, as it was not signed for that purpose. You can't use a client certificate to identify as server, and you can't use a server certificate to authenticate as client. You can however use the same key to create both a client and a server certificate.

As it turns out, you can indeed use a client certificate for purposes of host identification, and vice versa. This seems to me like a bug.


Forgot password to 7-Zip archive I think I already know the answer to this question, but I thought I'd ask the experts anyway.

A few months back, I created a password-protected 7-Zip archive which housed the source code of a simple program I was writing at the time. I was using the archive everyday, and so never wrote the password down. I've been racking my brain since finding the archive on my hard drive earlier in the week trying to remember the password, but I'm sure it's long forgotten.

I was wondering if there is any way to brute-force this password, or if it is even possible?

The password is at probably 4-13 chars long, and more than likely alpha-numeric with symbols too. It doesn't contain essential files, but I'd like to recover the code if at all possible.

If it's a 4 character password, you can do it.  If it's 13, good luck.

Rarcrack, under the GPLv2 license, is one of the few cracking packages that has a mode for 7z files at this time.

A tip from MyDigitalLife.info shows that if you start rarcrack once, then stop it, you can edit the abc element of its XML config/status file to limit the character set it searches.
If there are any characters you can eliminate, do so; it'll shrink the keyspace significantly.

If you're reading this thread after March 2014, see if there's a version of John the Ripper that lists 7z files; as of today, there is not, it's merely listed for the future (indeterminate).

Edited 2016: oclHashcat now supports 7-zip format as well, and is definitely a superior product.


Data Integrity in PKCs This is a simple question but one which greatly confuses me. When you have a PKC, the public key can be accessed by anyone. Therefore, doesn't this mean that anyone can encrypt data? My question is basically that if you have such a scheme where the public key is used to encrypt some instructions, the receiver can end up decrypting rogue instructions does it not? In such case, the receiver would need to do some security checks upon decrypting the message.

Looks like the PKC's purpose is purely the security of the message itself, and not the actual integrity of data.

Yes, anyone can encrypt with a public key but the use of keys in this case isn't for non-repudiation i.e. proving who sent, but only ensuring that only a specific recipient can decode and read the plain text i.e. that any interceptor of the message can't read it. This is the confidentiality part.

In order to ensure that the receiver can trust the sender, the sender needs to sign the encrypted file in some way, i.e. use some system to prove to the recipient that one person sent the file and that sender can be 'proven'. In public key systems this is done by the sender hashing the file they have encrypted and then encrypting that hash with their private key. The receiver then uses the public key of the signer/sender to decrypt the encrypted hash and comparing it with the hash they generate from the decrypted file, and, because only the sender can have created that hash, the receiver knows, beyond doubt, that the sender was the person who they said they were. This is the integrity part.


Is a 3 or 4 digit CVV enough for online transactions? Background: The CVV/CVV2 number ("Card Verification Value") on a credit card or debit card is a 3 or 4 digit number printed on the card.  It is 3 digits on VISA, MasterCard and Discover branded credit and debit cards, and 4 digits on an American Express branded credit or debit card.  The CVV code is not embossed on any of these cards.

My question: Is 3 or 4 digits enough for online transactions to be secure?

The credit card companies are aware of this, their anti-fraud detection software will block a card if they see more than a small number of attempts with incorrect CVV codes. Even having an understanding of the algorithms for generating CVVs a hacker would still have to get lucky to successfully be able to make a transaction.

As for whether it is a great system then the answer is no. It's still vulnerable to fraud, however it is much better than no CVV code at all. It's a quick and easy fix to add more security into the system until the industry can agree on a more permanent solution.


Key management in cloud datacenters In terms of infrastructure, how do Cloud providers (organizations providing SaaS, PaaS, or IaaS via the cloud) manage keys and cryptography?

From my understanding, "private" datacenters tend to manage and offload cryptography with dedicated hardware appliances (such as HSMs, ADCs, or SSL accelerators). In that case, asymmetric keys are managed directly on this dedicated hardware.

For a cloud provider that may have more than one datacenter and deals with many distinct and dynamic customers I find it difficult to see how it is possible to use dedicated hardware based solutions to manage and generate customers' keys.

My questions: are dedicated security appliances implementable in a cloud datacenter? How are keys typically managed and where are they generally stored?

Some HSM (I am more used to those from nCipher) allow cloud-like operation: several HSM may share the same "security world", which means that they see the same private keys, which they exchange with each other through encrypted tunnels. Storage itself is not, physically, in the HSM; it is external but encrypted with keys which are kept within the HSM (the complete setup involves several types of smartcards and it is a bit more complex than that, but you get the idea).


Ordering of the PATH environment variable Locally here on Ubuntu 14.04, my $PATH looks something like this:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

When I manually define the path for cron jobs or in Puppet/Ansible provisioning configuration, I usually flip the PATH environment variable around like this:

PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

Is there a security best-practice for ordering the entries in the PATH environment variable? I'd assume that it'd be best to prefer entries in an sbin directory over entries in a bin directory. I've noticed that on certain RHEL boxes, the PATH omits /sbin by default.

That said, what would be a security best practice for the PATH environment variable for:

User Unix accounts.
Administrator Unix accounts.
Cron jobs/configuration management processes.

If there's a directory in the search path where someone you don't trust could write files, then the directory should not be in the path, period.

The order only matters if a command is present in more than one entry in the list. So the only case to consider is when someone trustworthy arranged to have one entry shadowing another, deliberately or not.

If it was deliberate, then the order should be to search the directories in order of local management: typically this means first ~/bin or equivalent if running under an account that has such a directory (not applicable to most system accounts), then /usr/local/bin, then the directories managed by the package manager /usr/bin/ and /bin.

In principle, there should not be any shadowing between sbin and bin directories. sbin directories are for commands that are only useful to a system administrator (this is why these directories are normally not in the path of users other than root). In principle there could be a command name for which you want to run a different executable as root, so sbin directories should be ahead of the corresponding bin directory — otherwise …/sbin/foo would never be executed since it would be shadowed by …/bin/foo for everyone.

The only case when there is an ambiguity is if there may have been accidental shadowing. In that case there isn't an obvious answer. Generally, it doesn't make much sense to put /usr/local/bin after /usr/bin: if you don't want the local administrator's choice of commands, then don't put /usr/local/bin in the search path at all (and remove /usr/local/lib from the library search path, etc.).

Between /usr/bin and /bin, in principle, one might want to shadow an executable from /bin (small version for boot time only) with one from /usr/bin (large version from a separately-mounted /usr partition), but tiny root partitions with a separate /usr are a very uncommon practice these days. It was a more common practice in the days when operating systems used significant disk space, but even then shadowing utilities in /bin with versions from /usr/bin was uncommon. The other order, putting /bin first, has a slight performance benefit (/bin is usually a lot smaller). On most systems there's no strong reason to prefer one order over the other. (On some systems /bin and /usr/bin are the same directory, but you shouldn't assume that unless you only ever work on recent versions of one of the distributions that do this.)

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin (or PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin) is usually the right setting for jobs running as root, and PATH=/usr/local/bin:/usr/bin:/bin for jobs not running as root. I don't see any good reason to deviate from that (except for the /usr vs. / inversion) except to cater for local variations (e.g. a site-specific directory on *BSD distinct from the packages installed to /usr/local). Security-wise, it doesn't matter, but functionality-wise, putting /usr/local ahead of /usr and / is either indifferent or necessary.


What general security issues could arise from using UUID version 1 which exposes the MAC address? I'm coding GENERIC_WEB_SERVICE, which could potentially be running as multiple instances on multiple machines down the line. I'm using UUIDs as identifiers, and haven't settled yet on whether to use version 1 or version 4.

In this case, I have absolutely no idea what the implications are of exposing the MAC address by using version 1. I don't think I'm concerned about exposing the generation time.

So:

Are there potential issues?
I could apply an XOR mask over the portion of the UUID that represents the MAC address. The same mask would be used by every instance of the running service. Does this sufficiently handle aforementioned potential issues?

An UUID is meant, by construction, to be unique worldwide. Version 1 UUID achieve that in a context of cooperating entities. However, MAC addresses and current time are not exactly secret values; if someone observes several version 1 UUID produced by a given machine, he may succeed at predicting the value of future UUID produced by the same machine. Depending on what you use the UUID for, this may or may not be a problem. Note that hiding the MAC with a XOR mask or anything like that does not fix the issue.

Version 4 UUID use 122 bits from a cryptographically strong PRNG, which makes them unpredictable. That's stronger, and better. This ensures uniqueness even in the presence of hostile entities.

Summary: if unsure, use v4 UUID.


How can I check the integrity of a Bitcoin tarball with GPG? I plan on running several so called Full node servers with bitcoind (Bitcoin Core daemon).

All servers are running GNU/Linux Debian Stretch.

How do I verify integrity of the downloaded tarball with a GPG key and SHA-256 hash?

I downloaded the files from The official download page.

First, I downloaded the file I want to check, over a secure connection:

wget https://bitcoin.org/bin/bitcoin-core-0.15.1/bitcoin-0.15.1-x86_64-linux-gnu.tar.gz

Then, I downloaded the hash sums containing file over secure connection:

wget https://bitcoin.org/bin/bitcoin-core-0.15.1/SHA256SUMS.asc

Lastly, I downloaded the release signing key:

wget https://bitcoin.org/laanwj-releases.asc

Updated for the latest version: 0.15.1

You need to verify the signing key's fingerprint, before you import it:

cat laanwj-releases.asc | gpg --with-fingerprint --with-colons - | sed -ne 's|^fpr:::::::::\([0-9A-F]\+\):$|\1|p'

It should say:

01EA5486DE18A882D4C2684590C8019E36C2E964

Do not continue, if it does not match!
The signing key needs to be imported:

gpg --import laanwj-releases.asc 2>&1 | grep 36C2E964

It should say:

gpg: key 36C2E964: "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" imported

Now, we check the hash sum containing file's signature:

gpg --verify SHA256SUMS.asc

It should say:

gpg: Signature made Sat 11 Nov 2017 02:52:22 PM CET using RSA key ID 36C2E964
gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>"

And finally what we needed - to check that the hash sum of the file matches:

sha256sum --check --ignore-missing SHA256SUMS.asc 2>&1 | grep OK

It should say:

bitcoin-0.15.1-x86_64-linux-gnu.tar.gz: OK

In case it does not output anything, something's wrong and you may verify this by running it without | grep OK on the end.


Access encrypted files (dm-crypt/LUKS) through web app I'm a newbie to encryption issues and I'm trying to sort out a few questions.

For a distributed application we need to deploy a server outside of our company with sensitives PDF files on it. That because those files need to be accessed through another system (tablets fleet), and the huge amount of those files discard the accessing through the network from our servers.

I've been digging into dm-crypt/LUKS solution which seems to answer my problems, though I've a few questions:

Will a java app, deployed through tomcat, be able to seamlessly access those files ? My guess is yes if I start tomcat with sudo, but again, newbie...
Can I consider mounting the volume through the webapp ? I'm
considering retrieving the password to the encrypted partition
through a web service and store the password on one of our servers.
How bad is the overhead to decrypting those files on the fly? The
encrypted data will be accessed by a simultaneously by 4-5 users
retrieving around 50MB (decrypted size) of data.

Thx in advance for your help

> Will a java app be able to seamlessly access those files?

Yes, and you don't need sudo for that (NEVER RUN A WEBSERVICE AS ROOT). Once the luks partition is opened and mounted, application software just sees a normal filesystem.

> Can I consider mounting the volumen through a webapp?

Mounting requires root permissions, so you must be very careful when writing the webapp. Ideally, write a small suid executable that just does the mounting with a given password, and call that from the webapp, giving the webapp no special privileges whatsoever. Be very careful on passphrase handling - if you're not careful, the passphrase might end up in a log on the server or be viewable on the running system unter /proc.

> How bad is the overhead for decrypting on the fly?

For just 4 to 5 users decrypting only 50MB of data each, you won't notice the additional cpu usage caused by the decryption.

Note: As long as your server runs with the luks partition opened, anyone with access to the server will obviously be able to read all the encrypted files. Luks only protects data at rest (e.g. when someone yanks the hard drives from your server and runs away with them).


Has scrypt gone through enough testing to be considered secure? Five years ago, an extremely similar question was asked: has scrypt withstood the test of time. Since this was asked five years ago and some of the responses were mixed, such as:

"Scrypt has mostly survived." or "Everyone paying close attention to the Password Hashing Competition expects that Colin Percival will be submitting a revision of scrypt." or even "scrypt is only as good as existing iterative hash composition techniques".

Of course, with Moore's law, scrypt could be weaker or stronger (due to revisions) than it was stated five years ago.

So my question(s) are:

Is scrypt still secure?
Is scrypt better than bcrypt for password hashing?

Yes. Scrypt can be used securely. There are two sources of potential security problems: weaknesses in the algorithm design and errors in the implementation.

The design of scrypt is relatively simple, so implementation errors will be the only thing that could shock us at this point.

(Issues like buffer overflows, parsing mistakes, or use-after-free bugs. These are things to look out for, but they're not things particular to password hashing code. You are far more likely to find dangerous bugs in your operating system, web server, browser, or OpenSSL.)

As for algorithm weakenesses, there is no question that scrypt is better than bcrypt or PBKDF2. There is just one problem that makes it unsuitable for basic web app authentication. It was designed to be a key derivation function used for file encryption. It's not flexible enough for other uses, where time or memory may be more scarce.

That's why the password hashing competition was held. To improve upon scrypt. Developers should be incorporating Argon2 v 1.3 into new projects and should plan to make upgrades possible if they're curently using an older algorithm. (The only strong justification to consider using something else is if you're developing for a platform that inherently has extremely limited memory.)

There is no need to panic if scrypt is being use correctly in certain projects. Encrypted data is safe if you used a strong password and a large enough iteration count. Encrypted data is also safe if you used a unique (single use) and unpredictable password, regardless of the iteration count.

But what's bad about scrypt?

It has a single cost parameter. You cannot increase memory use without increasing run time.
It's time-memory-trade-off allows a password cracker to decrease memory. Cutting memory by a factor of n only increases run time by  a factor of n.
It takes more time to fill memory than Argon2 (on existing x64 platforms).
It would be easier to improve scrypt cracking hash rates using specialized hardware than it would be to improve on Argon2 hash rates.

So how do you use scrypt securely?

Make sure to set the iteration count high. Try to use a few gigabytes of memory.
Use randomly generated salts.
Use a trustworthy implementation. Not just any GitHub project. Keep up to date with security updates.
Design software such that you can increase parameters or migrate to a different hash algorithm.

The above four points are also applicable to using Argon2, but it's safer to use more or less time and/or memory. The advice for selecting parameters that accompanies version 1.3 of the PHC Argon project is good.


Detecting a MITM attack If my session is under a Man-In-The-Middle attack, can I detect it by checking the ip addresses my machine is connected to? For example, I want to know if my connection to a certain website is MITMed or not, I can visit the site and then use netstat -antp to find out the IP to which I am connected.

If I am MITMed, that IP will belong to the attacker, and be different from the actual website. Does that work in detecting an attack?

If the MITM attack was done using arp poisoning (for example in public WiFi network), then you will not see the attackers IP anywhere.

Lets say the default gateway of a WiFi network is 192.168.1.1. The attacker can send arp responses to your machine telling it that he is 192.168.1.1. Your machine will continue to send packets to the address 192.168.1.1, but the system will resolve it to the MAC of the attacker, and not to the MAC of the real gateway.

All the IP addresses of all websites you visit will remain unchanged from your machines point of view. Only the MAC entry of your default gateway in your arp table will have changed.


Usage of self-signed certificates for Client authentication We have a server to server communication scenario, where we would use a CA signed certificate for the TLS server authentication and would like to use a self-signed certificate for the Client authentication.

Is there any additional security that you would get by using a CA signed certificate as compared to using self-signed certificate in case of this scenario (client authentication) ?

UPDATED
We are importing the relevant Client certificates into the Server trust store / whitelist. Given this context does the CA signed cert offer any additional security benefits ?

[This is a re-write of the question addressing the update. See the original in the revision history]

TLS client auth is something that almost always requires you to extend your TLS engine by writing your own cert custom validation code on the server-end. It seems like you've avoided this by piggy-backing on the trust-store with no additional validation code.

The key question is:

  When your servers are verifying the client certificate, how do they know that it's a cert issued by you, and not a cert issued by a bad-guy?.

You say:

  We are importing the relevant Client certificates into the Server trust store / whitelist.

This might be ok security-wise. The first question to ask is what else is in the Server trust store, and if it will accept connections from certs other than the ones you whitelisted. Are we talking about the OS trust store containing all the publicly trusted root CAs, or is this a custom java trust store that is empty prior to you inserting your whitelist? For example, if the public CA Let's Encrypt is in the trust store, then anybody with a Let's Encrypt cert might be able to get a connection to your server.

Basically, you want to convince yourself that the self-signed certs you created are the only certs that will be able to establish a connection to the server. I have seen products that work this way, so it's not entirely far-fetched, and proper security is possible, however there are a few other things to think about. Let's first talk about the usual way this is set up, then I'll compare.

Usually, the way client-auth works in a situation like this is one of two ways:

Private CA

You have a private CA that you control. It only issues certificates for valid TLS clients. Therefore the TLS server can simply verify that the client presents a cert issued by this CA, and you know that it is authentic.

Public CA

Your clients get certificates from a publicly-trusted CA like Let's Encrypt. Suddenly, just checking that the cert was issued by Let's Encrypt is not good enough because half the internet has a cert like that, so that doesn't prove anything. Here, you want your "TLS server" to keep a whitelist of domain names of the "TLS clients". When validating a client cert, in addition to all the usual validity checking, it should that the DN in the cert matches a domain name on its whitelist.

Comparison of cert-whitelisting vs CA whitelisting

Revocation: Normally, as part of validating a cert, a TLS engine can be configured to check with the CA to ensure that a cert is not revoked. If one of your client servers is compromised, you can easily revoke the cert at the CA, and all subsequent connections from that cert will be rejected. In a cert-whitelisting model, you can still do this by removing the cert from the trust store. A bit more manual, but equally possible. Since this is non-standard, make sure you have a documented procedure for doing it.
Manual and error-prone: With a CA setup, you just need to import the CA cert once into the TLS endpoint, then you can issue / revoke as many certs as you like and the TLS endpoints will immediately start accepting / rejecting them appropriately with no additional config. With your setup, you will need to manually modify the trust store of the TLS Server every time you want to stand up or decommission a TLS Client machine. Avoiding the CA setup may seem like less work now, but think about the extra work over the long-term, and the added risk of a sysadmin down the line not really understanding how this non-standard thing works and blowing open the security - for example by adding a publicly-trusted CA to the Server's trust store without realizing the implications. Again, possible, but make sure you document procedures very carefully.

Summary

The security goal you want is that your TLS Clients (and only your TLS clients) can establish connections to your TLS Server(s). You can certainly accomplish this with the system you described. The initial setup will be simpler, but I predict that over the long-term the additional operational complexity will come back to bite you, either in terms of additional time and effort, or when it hasn't needed to be modified in so long that nobody remembers how it works. Make sure you prepare thorough documentation on how it works!


How to encrypt in PHP, properly? How do I encrypt data in PHP, properly, using symmetric-key encryption?  I have a message M and a secret S.  I'm looking for a solution that uses cryptography properly without making any of the usual mistakes.  In particular, the solution should use authenticated encryption, choose IVs properly, and generate the actual encryption key from the secret S using a suitable slow hash (in case S happens to be a password instead of an actual cryptographic key).

Can you suggest PHP code for this purpose?

My motive: I'd like to give PHP programmers good advice on how to do this, not bad advice.  This question on StackOverflow is a real disappointment: it is full of highly-upvoted answers that are appallingly bad (ECB mode encryption?  repeating IVs?  encryption without authentication?).  Let's figure out the right answer -- a code snippet that does things right -- and then go fix that broken window on StackOverflow.  In keeping with the PHP programmer ethos, I'd prefer a snippet of code (that works for as many settings as possible; possibly with explanation and/or explanation of limitations/caveats) instead of just advice about algorithms and concepts.

Can you suggest PHP code for this purpose?

In order of preference.

1. PECL Libsodium

If you haven't heard of libsodium, go learn about it right now. I very strongly recommend that you use libsodium if possible.

These instructions should get you started with installing libsodium and the PECL extension on your computer. The rest of that e-book should give you an understanding of how to use specific components, and contains plenty of example code. If you need a starting point for PHP cryptography to point non-experts to, libsodium is the best available today.

For secret-key authenticated encryption, refer to this chapter of the e-book.

2. paragonie/halite

(Disclaimer: I wrote Halite.)

All the power of libsodium, and an interface that looks like:

use \ParagonIE\Halite\Symmetric\Crypto as Symmetric;

$key = KeyFactory::loadEncryptionKey('/path/to/key/file');
$ciphertext = Symmetric::encrypt($plaintext, $key);

Check it out: paragonie/halite.

3. defuse/php-encryption

Defuse Security published an encryption* library on Github at defuse/php-encryption.

By encryption, I actually mean authenticated encryption:

Version 1:

AES-128-CBC with PKCS#7 padding and a random IV
HMAC-SHA-256 (verified in constant-time)
Uses HKDF-SHA256 to split your key into an encryption key and an authentication key

Version 2:

AES-256-CTR with a random nonce (CTR mode doesn't need padding)
HMAC-SHA-256 (verified in constant-time)
Uses HKDF-SHA256 to split your key into an encryption key and an authentication key; now with a random HKDF salt to mitigate the impact of birthday collisions in the random CTR after encrypting 2^64 blocks

Disclaimer: I'm one of the coauthors of this library, although most of my contributions won't land until the version 2 rewrite, which includes version tagging and a streaming interface for encrypting/decrypting files safely.

4. zend/zend-crypt

I recommend this one last because I have not personally audited it, but it is part of the Zend Framework and a lot of PHP security experts attest to its quality. Go ahead and use it if you're already using the Zend Framework.

Update: Since I originally wrote this answer, I did discover an issue in Zend\Crypt\PublicKey\Rsa (ZF2015-10 a.k.a. CVE-2015-7503). However, their symmetric-key encryption implementation appears to be secure.


Attacks on email validity service In order to have a better user experience during registration on mobile apps, I had added a web service to check if email ID exists before submitting the form. Based on the error logs, it looks like someone is misusing that API to check what email addresses exist in my database. Some of my friends told me attackers are using the email addresses recently leaked from some large organizations.

Is there a way to prevent such attacks? I doubt that closing down the email validity web-service is a good idea - almost all the authentication services seem to be offering this feature.

Note to moderators: I don't know what tags to use for this question, please do suggest some.

There is a way to delay such attacks in such a manner they would not want to spend time doing it. Make the check manual, and rate limit it per IP to 1 every X seconds. A user won't care much(depending on how long X is), and an attacker will. Especially if they want to check a LOT of emails.

To do this you'll need a cache of IP addresses that use that service, and give them a lifetime of X seconds. If they use the service and the IP is in the cache then respond with an error from the service.

Then in the form, after they're done typing the email for X seconds send of the request to check.

This will mean automated systems will not be able to use your service without delay as well, but you'd be surprised how useful that is in preventing these attacks when it no longer becomes worthwhile to them to spend time attacking it.


"There's a firewall on the router into the building so you can turn the one on your computer off" I know some people that, in regards to network security, argue that because the firewall on the router into the building is on, that makes the network secure and therefore, the firewall on Windows PC's can be switched off. These people work in IT.

I disagree with this and I need a solid argument to go back with. I am thinking that, if a computer on the network becomes compromised with malware, then an attacker taking control of this computer has already gotten past the routers firewall, and because the Windows firewalls are switched off they can then stroll through our LAN accessing any computer they wish.

Firstly, is my analysis correct? Secondly, what would you add to/remove from the argument I have presented above?

Your argument is a very good one.  I agree with you.

If it is too abstract for your IT folks, here is a way to make it more concrete.  Suppose one of your fellow employees catches a virus/worm while travelling, then brings his/her laptop back and connects it to your company network.  The worm will then be free to spread within your company network, without any firewall to stop it.  I have seen this happen in practice several times, and it is painful.

It is possible that your IT staff are concerned about the support cost of dealing with the firewall, and are worried it might break functionality and trigger more support calls to the IT folks.  Keep in mind that if your company deploys a local firewall on all your Window PC's, it is the IT staff who will have to deal with any increased level of support.  So their concerns may be legitimate.

If it were me making the decision, I think I would look at what are the downsides of running a firewall on your Window PC's.  If a local firewall would disrupt access to critical systems or would interfere with your business's core mission, then I would not run a local firewall: I would look for some other way to protect the internal machines.  However, if in your situation the local firewall wouldn't disrupt employees use of computing and wouldn't incur unreasonable support costs, I would enable the local firewall.

If people are unsure, you could start with a pilot: enabling the local firewall on a handful of Window PC's (maybe the ones handling the most critical information: e.g., payroll, or core intellectual property) and then track whether it causes problems.  The pilot could then give your company useful information to decide whether to enable the local firewall throughout the rest of the organization.


Guidelines for preventing HTML injection We have a tell-a-friend feature on our website where we present a form to the user for recipient email and personal message. The personal message is added to our email template. The email is sent on behalf of our website. Our form looks like this

What checks should we make to ensure that an malicious person cannot hack it and use it for its own/something else's publicity?

Recently, we had a case of email fraud where a malicious user was able to inject some html code in the input box provided for typing personal message. The received email contained a totally new email template (and our template at the bottom) and HTTP links to other sites.

Please add to the below points

Regex check for URLs and do-not-send URLs
?

It's quite simple (in theory):

Always escape user-provided input
Always do your escaping at display time. This prevents issues where you've escaped something for the wrong content type, and allows you to plug discovered holes without having to write a migration for old data.


Severity and priority rank of Insecure Direct Object Reference bug Recently, I found bug in an e-commerce web app and I will  report it.

The bug I found can:

delete and edit the favorite products list for all users
delete all notifications for all users

What severity and priority of this vulnerability can I report?

I'd actually say that sounds only moderately severe, because the direct harm that can be done is pretty minor. An attacker can breach a degree of confidentiality (information disclosure), can inconvenience people, can potentially deceive people, and can definitely damage the company's reputation, but can't directly cause much harm (e.g. force people to buy things, access information useful for identity theft, take over user accounts, or gain unauthorized access to the server).

I'd call it a pretty high priority, though. Direct object references are relatively easy to discover and usually also easy to exploit (i.e. usually it's just an integer you can iterate through), and the exploit can generally be scaled easily to affect a large number of people (they tend to be very amenable to automation and not require any interaction on anybody else's part). Ease of discovery and exploitation usually raise the priority, even when the severity is only middling.


DNSSEC signing algorithms Virtualmin supports a flurry of algorithms for DNSSEC: RSASHA1, RSASHA256, RSAMD5, DSA, DH, HMAC-MD5(???), NSEC3RSASHA1, NSEC3DSA.

If I understand correctly, there's Proof of Concept available for SHA1 being easy to compromise when used with DKIM, because of data length. So that would lead me to believe that the same applies to DNSSEC.

Which key algorithms are most appropriate for use in DNSSEC with production environments?

And what supporting technical papers are available to substantiate the reasoning for the algorithm choice?

There's a balance to be found here however, the same one that INFOSEC so often must find, in choosing an appropriately secure algorithim without zealously draining resources in production environments.

Still, an appropriate algorithm for vital cyber systems (financial or sensitive personal information) might vary from one for mission-critical systems.

Or is the threat from man-in-the-middle attacks too great in a global cyber diaster event, such that the strongest cryptography is warranted even for mission-critical systems without highly sensitive information?

(Yes, the question is old, but it deserves an answer.)

Some rules for modern crypto:

MD5 is dead
1024 bit RSA is dead
SHA1 is dying

Using an HMAC for DNSSEC makes no sense, an HMAC requires both parties to have access to the same secret; in the context of DNSSEC, this means clients could spoof the server, making it useless.

There's a lot of algorithms missing from your list, I don't know why Virtualmin gives you those options.  ECDSA options give you smaller responses and somewhat lower CPU usage in signing operations.

Given the relatively short lifetime of DNSSEC keys & responses, I would favor shorter options after taking all of the above in to account.  This means the use of RSASHA256 with a 2048-bit RSA key or ECDSAP256SHA256 (256-bit ECDSA with SHA256).


How do I store a user's secret key on a server? I'm learning about security at the moment and one thing I'd like to try out is having a key server distribute keys to clients that will allow them to securely save and read data locally.

My basic idea is that the client will communicate with the server over TLS where they'll provide a username and password. This password will be used to both authenticate the user and decrypt the key in the database.

Essentially the key server database would be laid out like so:

| User Name | Hashed Password+Salt | Salt | Encrypted Key |

In this case, would the keys be secure in the event of a database leak?
I'm wondering if there is a best practice for this kind of implementation or should I handle this differently?

(Disclaimer: I'm a "security student" myself, so I'm not 100% sure if this is correct.)

I don't understand why you would want to keep private keys on the server after they are transferred to the user. There is no use for them. If they are lost - create new ones.

Keys have a public and a private part. The public part can really be public and may be published on the web.

Private keys should be kept private, and this should mean that users have their keys on their own machine (laptop, phone etc), maybe even a unique key for each machine. They should be instructed how to keep that key safe there. A password comes to mind. If you create the keys for the user on your server, you need a way to get the private key safely to the user. This can be done locally, over SSH, or via USB stick, etc. Create the keys right before you transfer them, then delete them.

Maybe I'm missing something, a good reason to keep the keys on the server - then please explain why.


How do I import a GnuPG private PGP key into Symantec PGP commandline? I am trying to import a private PGP key into Symantec PGP command line that originated in GnuPGP (1.4.11 AIX) into a Windows system.

When I do a pgp --import private.asc, then do a pgp --list-keys --details I get an invalid key:

C:\Program Files\PGP Corporation\PGP Command Line>pgp --list-keys --details
Key Details: Bank (Joint key) <user@company.com>
     Key ID: 0x4aaaa8 (0x09aaaaaB8)
       Type: RSA (v4) key pair
       Size: 2048
   Validity: Invalid
      Trust: Never (Not axiomatic)
    Created: 2014-02-26
    Expires: 2016-01-17
     Status: Active
     Cipher: AES-256
     Cipher: AES-192
     Cipher: AES-128
     Cipher: CAST5
     Cipher: TripleDES
       Hash: SHA-256
       Hash: SHA-1
       Hash: SHA-384
       Hash: SHA-512
       Hash: Unknown 0x0B
   Compress: ZLIB
   Compress: BZIP2
   Compress: Zip
      Photo: No
  Revocable: Yes
      Token: No
  Keyserver: Absent
    Default: Yes
    Wrapper: No
 Prop Flags: Sign user IDs
 Prop Flags: Sign messages
 Prop Flags: PGP NetShare
 Prop Flags: PGP WDE
 Prop Flags: PGP ZIP
 Prop Flags: PGP Messaging
 Ksrv Flags: No modify
 Feat Flags: Modification detection
  Notations: None
      Usage: Sign user IDs
      Usage: Sign messages

  Subkey ID: 0xFbbbb5 (0x96bbbb75)
       Type: RSA (v4) subkey pair
       Size: 2048
    Created: 2014-02-26
    Expires: 2019-01-17
     Status: Active
  Revocable: Yes
      Token: No
      X.509: No
 Prop Flags: Encrypt communications
 Prop Flags: Encrypt storage
 Prop Flags: PGP NetShare
 Prop Flags: PGP WDE
 Prop Flags: PGP ZIP
 Prop Flags: PGP Messaging
  Notations: None
      Usage: Encrypt communications
      Usage: Encrypt storage
      Usage: PGP NetShare
      Usage: PGP WDE
      Usage: PGP ZIP
      Usage: PGP Messaging

        ADK: None

    Revoker: None

1 key found

Question

What is a "Joint Key", and should a PGP private key be "joint"
Is there any way I can tell if the ASC is expecting "wrapped" syntax?
How do I import a private key from Aix?

Actually this key is successfully imported and you can use it to encrypt data with it.

The "Validity" states do you have any evidence that this key was really created by its owner. It doesn't mean that it cannot be used. Check here for more details: http://www.pgpi.org/doc/pgpintro/#p17

The "(Joint key)" phrase is part of the key User Id.


How to securely login over HTTP when you have SSH access? I have a web app without TLS (I know it's not good, I try to take it as a challenge). The login has two steps: first, the admin sshs into the server and runs a maintenance companion program that provides a one-time (securely) randomized link. The one-time link leads to a login form. The one-time link is good for just 1 GET of login form and 1 form submit.

Does this actually give me more security? Could I do better?

Without SSL, your connection can be preyed upon by eavesdroppers: they can see the data, they can also alter the data, and generally hijack your connection once you have authenticated. They can do that regardless of the authentication method.

If you assume that there is no malicious individual who can see and/or modify traffic in-transit, then... there is no security problem, and basic authentication (as in "show the password") would work equally well.

So I can sum it up as: your one-time link obtained over SSH does not provide any significant improvement on security. Without SSL, the App was weak and is still weak. So I'd say, don't bother with it, in particular because forcing a SSH connection whenever a user wants to use the App is a big usability issue.

Instead, use SSL.


Is there a coordinated Firefox user-agent for anonymous browsing? One fingerprinting element is the browser's user-agent string. If we consider one browser, Firefox, we can see that it has different strings across different OSes, distros, forks (Tor, IceCat) and versions. Some of these populations would be very small (say, Guix SD users running the latest version of IceCat) and therefore individuals within those populations would be more easily identified (in combination with other data).

Has there been any attempt to coordinate user-agent strings among these communities? (Or resistance to such an attempt.)

Existing user-agent strings for popular releases would be de facto coordinated standards. These could include (in assumed order of popularity):

Latest Windows Chrome release
Latest Windows Firefox release
Latest Ubuntu LTS Firefox release
Latest Ubuntu Firefox release
Latest Debian Tor release

...but for greatest effectiveness smaller communities would still need to coordinate around one of these, and pick an UA that has limited/no effect on usability (sites that still sniff for browser compatibility).


Circumventing Device Fingerprinting Regarding the concept of device (browser) fingerprinting, would it be possible for the user to spoof fingerprinting data by giving random information such that your fingerprint changes after every request?

If so, are there any plugins/browsers that have this capability?

As far as I can see, you can easily spoof all of the fingerprinting data, and potentially change it with every request. All this information is sent by your browser in the HTTP headers of the request (or obtained via browser client-side scripts). I am not aware of a particular plugin that supports this fully, but there are some plugins for changing your user-agent, manipulating headers and managing cookies. The user-agent is one of the main identifying pieces of information of the fingerprinting process and most other pieces are in other various headers. Blocking javascript/flash scripts is also possible, e.g. using the noscript plugin

Changing this fingerprinting info however does come with a price. It might cause the website to display pages in a different way, which will cause the site to look wrong or not to function properly. Lots of website developers rely on (at least some of) this fingerprint information in order to make the pages they display compatible with your browser. Hiding/spoofing this info will therefore affect this process and your browsing experience may be altered.

It's also possible that this fingerprinting is performed for legitimate security reasons. For example, a security-aware website might tie in the fingerprint info to the session or logged-in user, and will reject requests where the fingerprinting doesn't match (this would suggest to the server a request is now coming from a different browser). Here's one more example from another question where the website owner wants to test browser plugin versions of your browser (which is part of the fingerprinting data) before allowing access. I don't know of any specific sites that use this technique, but it is definitely feasible. Changing fingerprint data with every request will again cause unwanted behaviour.

I suppose that performing some minor randomized tweaks to specific headers will achieve a better degree of anonymity against fingerprinting without compromising the browsing experience. This requires some experimentation and will probably mean a compromise between security and usability.


What is more secure: ISDN, Cable Modem, DSL, T1, etc...? This discussion came after showing a friend this Security.SE post  regarding DNS attacks, and after reading about a Cable Modem MITM attack.

Given the current options available to consumers, what medium (ISDN, Cable Modem, DSL) is inherently more secure than the others?

On the physical medium part, eavesdropping on a phone landline where dialup modems are used is physically easier than spying on the more modern mediums, because the lower data rate more easily accommodates homemade electronics of questionable quality. Also, some of the protocols used over various mediums include encryption, which may hinder spying attempts on the physical line (at some point, I had an ADSL access with PPTP and some sort of encryption activated -- although I do not know how good it was !).

Although marauding in deserted courtyards during moonless nights, crouching under service boxes to add tapping wires, is a time-honoured spying tradition, I believe that most attacks nowadays will be on a logical layer -- the attacker will try to hack into the ISP systems, or the machines on the customer side, be it a cable/DSL-modem or a not-totally-updated desktop systems, and he will do so by sending IP packets from far away. These are mostly orthogonal to the question of what medium is used. Logical attacks allow the attacker to try his luck on millions of targets from the comfort of his own basement, instead of confronting rainy gloom and ill-tempered cats on the random chance that the dozen or so homes that he will approach that night may contain something valuable, electronically speaking, and that no bored insomniac will spot him and call the police.

Physical spying still exists, but is mostly employed on specific targets: the attacker does not want to spy on anybody, he is after you, personally. At which point you should have more pressing needs. Proofing a home network against a dedicated attacker is hard; think about TEMPEST or even about looking at your display and/or keyboard, over your shoulder, from the outside, through a window. A good telescope, a video camera with high fps (nominally for slow-motion), and you can record a typed password from 200m away.

So for the specifics of DSL/T1/Cable/ISDN, I would advise selecting the provider: choose an ISP with a good repute about security issues, in particular with regards to whatever modem he provides. That's more important, security-wise, than the physical medium. And, to abstract the whole question away, never do sensitive stuff over the Internet unless you employ appropriate logical protection, such as HTTPS.


Code Injection detection on Web Servers Recently I found one of my web servers hacked with malicious code injected to websites hosted there. It wasn't exactly my fault, as I shared the server with other people and someone put some unsafe script/website on the server. Luckily to me there was no damage or data loss. But it got me thinking. I found out about the breach totally by accident. I simply tried to pull a some updates to another script from my Git repository and it returned an error about uncommited modified files in my working copy.

In most cases there is no access to shell on web servers (shared hosting) and you update websites by uploading them via FTP and simply overwrite files. How to detect Code Injection is such situation?

And what about the situation where you have access to shell on your web server. Are there any other (and better) ways/tools to detect Code Injection?

Summary. The best defense against code injection is to prevent it in the first place.  Generally speaking, once malicious code has gotten onto your system, there is no reliable way to detect it.  I know that you were asking about detection, but I recommend that you focus on prevention, not detection.

Prevention. So, how do you prevent code injection?  Generally speaking, through access control, good security hygiene, and secure software development processes.

If you have a web server, don't share it with other people.  It is easy enough to use virtualization to provide isolation between multiple tenants.  For instance, if you buy shared hosting from a commercial shared hosting service, they will use some form of virtualization to isolate their customers from each other.  (This has nothing to do with FTP access vs shell access.  As long as the customers are isolated from each other, it doesn't matter whether the hosting provider provides shell access or FTP access.  They just need to make sure that other customers get access only to their virtual containers, and not to yours.)  Similarly, don't share your passwords or cryptographic keys with others.
Practice good system administration practices, to prevent compromises of your server.  Keep your software fully updated and patched.  Use firewalls to limit access to only those services you want to expose.  Use SSH with public-key authentication for remote login.  If you need to use passwords, make sure you choose long and strong passwords, never share them, and only send them over encrypted channels.
Practice good software development processes.  Avoid introducing security vulnerabilities into software you write.  Entire books have been written about how to go about doing that, so I won't try to explain in detail here; I'll simply flag it as something that's important, to ensure the software is free of security vulnerabilities.


How to detect WiFi spoofing? I have recently become concerned that someone might be spoofing the WiFi network at my office. The network has been really unstable these last few weeks. The password isn't really that secret, and I'm guessing that if someone had the SSID as well as the password, someone could configure a fake router with the same MAC advertisting the same SSID and password. Is that possible?
Are there any tools for Windows that can be used to see if there is an unsual amount of broadcasts for an SSID with the same MAC? Or are there other ways to detect this?

To begin with, Wifi spoofing is named as Evil Twin attack. You can find more information about it if you search as "Evil Twin Attack" rather than "Wifi Spoofing".
I have found a good article about the attack: What is evil twin?.
Plus, there is a good explanation about how to commit it on Null-Byte.WonderHowTo. ( for learning purpose only ).

There is no need the attacker to know about your password. In addition, he does not even need to spoof your MAC address. Detecting Evil Twin is already explained well in How would you detect an Evil Twin attack, especially in a new environment? . So you can read it.


Secure OS deployment I want to deploy operating system images on quite a lot of clients. I know that the images must contain the latest security patches, as well as hotfixes (assuming they are tested and approved for the target environment). They also have to be configured to receive regular updates from a certain distribution point. Moreover, I know (see this Q&A) that the PXE installation must be performed in a contained environment, so that an attacker cannot install rogue devices and services.

Are there other security precautions and/or best practices to follow when preparing and deploying OS images?

PS: Here's some additional information, just in case: The client OS is Microsoft Windows 7 x64. I'm deciding to use tools such as Windows Automated Installation Kit, Microsoft Deployment Toolkit, Windows Deployment Services, and System Center Configuration Manager to prepare, deploy, and manage the OS on the clients.

I accomplished this using WDS and MDT. The biggest problem as you gave mentioned is that the boxes aren't secure whilst the latest few rounds of updates are being installed.

Keeping the windows firewall enabled and restricting exactly who and from what computers these sensitive machines can be accessed can easily be accomplished by the ipsec rules and restricted group membership deployed via group policy. We have a whole separate firewall policy for our new build OUs.

To minimize the danger from a rogue dhcp / tftp server I prefer to keep the server on the same subnet, not forward broadcasts and only apply the vlan to the ports associated with my bench.

I use solar wind's patch manager which uses wsus under the hood. This is set up using https to verify any later patches are securely transmitted. We also sign all patches we assemble in house.


How much is the entropy of a randomly generated password reduced if I regenerate until I get a password I like? In many of the answers and comments on the well-known XKCD #936: Short complex password, or long dictionary passphrase? question, the importance was stressed of generating the password randomly, and not just making one up. In particular, the current second highest voted answer on that question says:

  Random choices are random and uniform. This is hard to achieve with human users. You must convince them to use a device for good randomness (a coin, not a brain), and to accept the result. This is the gist of my original answer (reproduced below). If the users alter the choices, if only by generating another password if the one they got "does not please them", then they depart from random uniformity, and the entropy can only be lowered (maximum entropy is achieved with uniform randomness; you cannot get better, but you can get much worse).

This got me wondering: what if I don't accept the result and instead generate a new random password? How big of an impact would that have on the entropy of the final generated password?

Presumably the more times I allow myself to reject a password, the more the entropy of the final password could potentially be reduced, so let's say for example that I generate 8 passwords and pick the one I like best. How much could that potentially reduce the effective entropy of the password I select? (Maybe log_2(8) = 3 bits as a worst-case scenario?)

Your rejection/acceptance of a truly randomly generated password, and how many times you reject until you accept, will not affect the entropy as the entropy is determined in isolation from generation to generation (just like each toss of a coin doesn't affect the entropy of the next toss). All strings have the same entropy, it's only the context of evaluation that determines the 'subjective entropy' (which isn't relevant).

But, the strength of a password isn't directly linked to its randomness - as you suggest - if you ask for a random sequence of 11 characters from letters and numbers then you could get password123 as your first random sequence. It would be completely random, just not very strong. It would have the same entropy as the next generation.

Similarly, although the entropy isn't less or more, if you keep generating random strings until you 'like' one you are more likely to select a weaker random string of characters (well, if your 'liking' is based on typical human considerations such as memorableness or lyrical quality or pronounceability etc.)

So entropy and human liking aren't connected, but liking and password strength most certainly are.


What are the security implications of having a dummy user account representing unauthenticated users? In my web application, users are assigned to groups and groups are granted permissions on objects. The application exposes some objects to unauthenticated public users (i.e. people casually visiting the website).

I have thought about having an object attribute of "visible to public" that grants unauthenticated users that access.

I have also thought about creating a group named Public, and giving that group permissions like any other group - then automatically treating the unauthenticated user as a "dummy" user who is a member of that group.

The latter seems simpler from the perspective of the interface (both API and UI) for managing permissions. But the concept of the Public group being special feels like a slight design smell. Am I missing any security principles that would make this undesirable?

It sounds like your following good security principles by establishing secure defaults, trying to keep it simple, and ensuring guests have least privilege.

I think both of the two options are viable and should be left up to you, the programmer. Whatever you think is simpler and easier to manager long term is probably the right choice.

If a visible to public object is going to be easy to manage the access rights on whatever content you wish, use it, as long as it also provides easy functionality to change what's visible in the future.

I personally would lean towards creating a permissions group for guests, and assigning them to that group by default because that's what everyone is used to managing. It would also permit someone to manage the permissions of all the guests in the same way that one would manage the permissions for everyone else. Remember, keep security simple.

  Attack surface area and simplicity go hand in hand. Certain software
  engineering fads prefer overly complex approaches to what would
  otherwise be relatively straightforward and simple code. Developers
  should avoid the use of double negatives and complex architectures
  when a simpler approach would be faster and simpler.

Read more on security principles here - owasp.org


My Yahoo accounts keep making random accounts for me on other websites. Why? I have two Yahoo email accounts. Both will randomly recieve new emails about a new account that was made under my name and my email address, however, I'm not setting up these accounts. I have had multiple accounts created, using my email address, monthly on sites or apps I've personally never been on. Is my account hacked? Could someone be trying to set me up to make it look like I'm creating accounts?

If you are uncertain whether your account has been hacked, you should immediately reset the password. If your account was hacked, some damage may have already been done, but setting a new password will prevent any further damage.

However, some sites allow you to create an account without first verifying your email address. This should not be alarming, and it is something that site should improve on their end. You can contact them to ask your account be deleted.

The better sites will require an email confirmation before someone can make an account with your email address. In this case you should simply 'not confirm' your account when they ask you to.

If your email account was hacked, though, the attacker may have already clicked the appropriate confirmation link. In this case you should contact the site owners and ask your account be deleted - since you did not make it yourself.

After the cleanup is underway, you should look at securing yourself. If you think a virus has caused the password to get out, then a professional machine wipe is the safest option. However, sometimes a password is accidentally leaked by phishing (entering your Yahoo password on a Yahoo-look-alike-fake-site), in which case you would not need a machine wipe.

As another answer just mentioned, using 2-factor authentication is a real boost in your security, but not a silver bullet.


Is my data safe if, with an encrypted hard disk, I put Windows in "sleep" mode Both my boot partition and my data partition are encrypted with TrueCrypt. My password is lengthy, so I find myself avoiding a reboot of my system whenever possible. When going to lunch (for instance), I have been putting my laptop into "Sleep" mode, which requires me to enter my Windows password to get back into Windows. (My Windows password is weak; more to keep the kids out of my account than anything else.)

I'm aware of software that can remove Windows passwords easily, but I am not aware of a took that can remove a password without rebooting. (If they reboot my machine, they will have to re-enter my TrueCrypt password.) How sophisticated would an adversary have to be to get data from my computer when it is only in "Sleep" mode?

For virtually all disk encryption tools, your encryption key will be stored in RAM while the computer is in use or in sleep mode. This of course presents a fairly significant vulnerability, because if someone can dump the contents of your RAM while keeping its contents intact, it is likely they can extract the key from the RAM dump using widely available commercial software such as Elcomsoft Forensic Disk Decryptor which claims to extract Truecrypt, Bitlocker, and PGP keys.

To protect yourself against this, you'll have to make it harder for an attacker to obtain a RAM dump. The easiest way to obtain a RAM dump is by using software programs that come with many forensics toolkits (which are also freely available). However, the catch is that in order to run these programs, they would first have to unlock your computer. If they can't unlock your computer to run programs, they can't launch any RAM dump utilities. For this reason, having a strong Windows lock screen password is important!

(Also, just to be realistic and state the obvious, the lock screen password is also important because if an attacker is able to guess it, they could just grab a copy of your files right then and there and not even worry about finding your encryption key. For a run-of-the-mill thief interested in obtaining your data, this would probably be the most realistic threat IMO)

A more sophisticated way is to use a cold boot attack; this takes advantage of the fact that contents of memory will remain there for some time (from a few seconds to a few hours if the RAM is cooled with a refrigerant) even after power is turned off. The attacker can then bypass Windows and boot into a RAM dump utility or physically move the RAM to a different machine for reading. This kind of attack significantly harder to protect against.

Lastly I'd also mention that development of Truecrypt stopped a year ago for unknown reasons and it is no longer supported, so I would recommend moving to one of its forks such as Veracrypt.


RSA or ECDHE for x.509 certificates-what does each do? I am relatively new to x.509 certificates, but recently i have been looking at the https connection padlock at the top of the screen. On certain websites, clicking on the pad informs me that the site is being securelyconnected through a key exchange, ECDHE, and these keys are signed with RSA. But, when i open the full certificate for the site, the public key is RSA 2048 bits. This confused me, as i thought the public key should be ECC 256 bits, and not an RSA key, as the key exchange is ECC, and not RSA.

I'm probably just missing something really obvious, but any help would be appreciated.

The public/private keys are (fairly) static and are normally 2048 bits or even 4096 bits - they are used early in the TLS negotiation, to verify the site's identity (and the client's, in the case of a client certificate) and to negotiate using asymmetric encryption a new key that will be a) shared between the client and server, b) unique to this connection and c) symmetric.  This is the key that is actually exchanged and is shorter and what is used for actual transport.

Asymmetric encryption is (relatively) slow - that's why the session is actually encrypted with symmetric encryption.


What's going on with this URL? Has the honda website been hacked? Here's a URL that you may not want to open (should be fine with a modern browser though):

http://www.primavera.honda.com/ga01/fwsg8.php?teu=boat-puns-captions

It seems to redirect through a bunch of different spammy, malware-type sites.

What's going on there? That's Honda's domain, right? Is this part of a blackhat SEO network or something? I've tweeted Honda just in case.

Edit: Definitely looks like this is the work a (wordpress?) hacker. Here's a bunch more that I found via google:

http://www.truenorthpsychiatric.com/zoiruhe/uonirue.php?altr=RIP-boiling-water-You-shall-be-mist
http://www.seculardirectory.org/vyke/yjzi7.php?teu=disney-pun-team-names
http://studentvoicei.org/5vvy/r2bhj.php?teu=meme-account-name-ideas
http://www.angelcitycars.co.uk/zoiruhe/uonirue.php?altr=Was-Kid-Rock-ever-Cool
http://passatonce.co.uk/8dut/nyx0a.php?teu=words-pun-generator
http://www.trustligas.com.br/yg6k/il8ds.php?teu=water-pun

And this one has the <title> element changed to "Hacked by CyberPirate !":

http://falkontravel.com/ehxg/5xqgk.php?puc=paddle-puns

Seems like there are hundreds of sites like this (in google search results) that have been compromised.

That's Honda's domain, right?

Yes it is. Either one of their web servers or their DNS has been compromised.

  Is this part of a blackhat SEO network or something?

Most-definitely. A domain for a large company linking to other websites raises their page rank.

Of course, it's possible the compromised web server is also up to other nefarious things.


What should I do, if my information has been compromised in the Apollo breach? I received a message from haveibeenpwned.com that some of my information has been compromised.

The link in the screenshot below refers to this article.

What should I do as a response to this?

I don't remember whether or not I ever entered any information into this Apollo service (I don't even remember that I ever used it). I assume that they somehow harvested my data from other sources (e. g. social networks). I use different passwords for different web sites and I don't know which passwords were compromised. Changing all passwords is not an option (there are too many of them).

Apollo is not a service you would have directly interacted with.  They sift through public information on the internet (twitter, company websites, linked in, etc.) to collect contact information, such as names and emails.  They essentially gathered massive amounts of data which businesses would then pay them for in order to find sales leads.

You don't have any passwords that need to be changed, because no passwords were exposed.  The only real danger is that all this public information is gathered together in a single place, which makes it easier for scammers (phone or phishing) to fool you into falling for their scams.

Just stay skeptical of offers that are too good to be true.  Be wary of anyone who is trying to scare you into making a quick decision.  I'm not saying be paranoid, but be aware.


What is the standard practice to maintain a password for different websites? I have come across many users who maintain a re-used password for each and every website, such as P@ssw0rd123

The problem with this approach is if someone breaches the protections of a particular website then user security will be in vain.

Many websites still store passwords in the database in an unencrypted format. Suppose I have access to the database of a particular website. Then I can steal the username and password and just imagine the havoc that I can create with the users who re-use passwords for every website/portal/platform.

How to solve this problem? What algorithm should a user follow to maintain the password for different websites/portal who have no knowledge of security and other technical stuff?

This question is intended for general purpose users who don't have any knowledge of security, so tools like password card, password manager or hash tools not going to solve the problem.

Instead how about having the password like

domain_name + combination of unique keywords per website + unique special characters per website ?

There are different mitigations suggested like for example PasswordCard or some hints how to extend your password with the site name or even hash tools.

But the only best practice is to use a password manager with a strong master password and generate random passwords for each site.


Does http.sys vulnerability affect Windows not running any webservers? Windows kernel level HTTP driver http.sys is affected by remote code execution vulnerability (MS15-034).

  This security update resolves a vulnerability in Microsoft Windows.
  The vulnerability could allow remote code execution if an attacker
  sends a specially crafted HTTP request to an affected Windows system.

  This security update is rated Critical for all supported editions of
  Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012,
  Windows 8.1, and Windows Server 2012 R2.

What's not clear to me is if http.sys would be running and listening on a Windows machine, which does not have web server installed?

Post on installing nginx on Windows would suggest that http.sys is running regardless. Is that the case or would it be disabled by default on desktop Windows versions?

IIS is one of many applications that get HTTP requests passed to it from HTTP.sys, so HTTP.sys can be loaded without IIS running or even being installed.

Windows implements an HTTP listener as part of the network subsystem via a kernel mode driver (HTTP.sys).  HTTP.sys is what's actually listening for HTTP requests and passing it on to the application responsible for processing the request (e.g. IIS/WinRM, etc.).  It's also responsible for passing the HTTP response back to the client application (e.g. web browser, powershell, etc.). Hypertext Transfer Protocol Stack (HTTP.sys)

Examples of applications/services using HTTP.sys:
ADFS, Powershell Remoting (uses WinRM), SSDP (Simple Service Discovery Protocol), UPnP (Universal Plug and Play), Web Application Proxy, Win Media Extender, WinRM (Windows Remote Management)

Note that you can run netsh http show servicestate to see what is using HTTP.sys.


Refresh tokens with SPAs We've been working with SPAs which POST through credentials to the API and receive back a JWT (access token) and refresh token.  The tokens are stored, depending on the 'keep me logged in', in session storage or local storage.

Looking at https://auth0.com/docs/api-auth/which-oauth-flow-to-use, they suggest (via OAuth 2.0, sure, but same concept I think) that SPAs should not be trusted with bearer tokens.  Instead, we should do a silent auth by (in their case) having a hidden iframe and grabbing the access token directly.

Basically, my question is, why is the advice here, "SPAs cannot use Refresh Tokens"?  In their example of using an iframe, I'm guessing there's a cookie being stored for their OAuth login domain - how is that inherently better?

What else might I be missing?

Edit: am I right in thinking XSS is more possible when using session storage, CSRF is more possible when using cookies, and so the answer is, if you have high confidence one of those (XSS/CSRF) is protected against, then that associated storage (session/cookies) is the way to go?

The security level is the same if you:

have HTTP header: X-Frame-Options: SAMEORIGIN
header: X-XSS-Protection: 1; mode=block
SSL with HSTS header
if you use cookie to protect it use CSRF tokens.

They say iframe just to hide refreshes from users no other then that,
but security stays on the same level as without it if above is done.


Is it safe to log into crypto exchange account using coworking space or coffee shop wifi network? I day trade cryptocurrency and want to start using coworking spaces for faster internet access.

1.a. Is it safe to log into my exchange account using the coworking space network?

1.b. What questions should I ask them about their network's security [to make sure other people on the network cannot access my data]?

Sometimes I go to a coffee shop but never log into my account because I have read that hackers can intercept my data and can potentially steal login details.

2.a. Can it ever be safe to use a coffee shop, or for that matter hotel and guest house wifi? What if I use a VPN such as Kaspersky's secure connection?

1.a. No. Any shared network that you do not control exposes risks.

1.b. Practically, I doubt any question will solve the reality of 1.a.

2.a. See 1.a.

VPNs are exactly the tool for this problem. They create a secure tunnel out of and through untrusted networks. We cannot speculate on the security of any one product or service, although paid options are more likely (caveat emptor) to provide you with better security.


CSP report-uri does not work I'm using the following PHP script to test CSP policy,

<?php
   header("Content-Security-Policy: default-src https:; report-uri /report.php");
   header("Content-Security-Policy: default-src 'self'");
?>

<html>
   <body>
        <script src="http://google/abc.js"></script>
   </body>
</html>

The CSP policy works,

But the report-uri part didn't. The reporting request was never sent and no relevant entry in nginx access logs

Any ideas?

From the Content-Security-Policy standard:

  A server SHOULD NOT send more than one HTTP response header field named "Content-Security-Policy" with a given resource representation.

But, you are using multiple Content-Security-Policy headers. The behavior is not defined for this case. But it looks like that the browsers in this case only use the latest header. This means your first header which specifies a report-uri gets ignored and only the second header use, which does not specify a report-uri.


Recover password from .pfx file I have an old Windows SmartClient application that is published with a signed certificate (a .pfx file).
We want to extend the expiration date to more than one year. I've used a program called RenewCert to do this with other certs. However, we don't know password to this cert, which is required by RenewCert. I tried using a program called CertificatePasswordRecovery to recover the password, but it could not find it.

The only choice now seems to be to generate a new cert, which will require a uninstall/reinstall of the application on all machines.

Is this correct? or can you think of any other possibilities?

Edit: more info:
I saw another potential solution on the internet where you open the file in notepad and search for the signtool.exe and the password will follow the /p switch. I was not successful, but I'm not sure if I approached it correctly. In notepad, I just see a bunch of chinese symbols. Then I tried looking at the pfx file in Ultraedit, in both text and hex mode, but I didn't see anything like "signtool.exe". I looked for ascii hex of "sign" - 73 69 67 6e - but didn't find it.

First, I have an issue with nomenclature: articles like the one you linked to sortof suggest that the terms "public/private key pair" and "certificate" are interchangeable. In reality, a certificate is just the public key part of the key pair, and a .pfx file is a bundle that contains both the certificate (public part) and the encrypted private key [source].

(It grinds my gears when people talk about a "password protecting a certificate" which makes no sense since a certificate is public information! You really mean "password protecting a private key". But since the PFX format encourages people to think of it all as one bundle, I guess this is forgivable.)

Based on that article you linked, it looks like RenewCert is using the private key associated with that certificate to generate a new self-signed certificate containing the same public key as the old cert (and getting a longer expiry date on it in the process). Self-signed certs would fail in HTTPS, but your SmartClient applications should be fine with it. Certificates need to be signed by somebody's private key, so  RenewCert is using the same keypair that you are certifying to do the signature (hence "self-signed certificate").

The other way to renew a certificate is by submitting a certificate signing request (csr) to a certificate authority (CA). Unfortunately, here too you need access to the private key so you can prove to the CA that you own this key through a proof-of-possession [see RFC 4211 Section 4. and an IETF statement about POPs in CSRs].

So the answer to your question is: unless you can find a way to access that private key (by remembering the password on the .pfx file, or by finding the private key in a backup somewhere) your only option is to generate a new keypair, make a completely new certificate, and update all the applications. No way around that... the whole point of certificates is to prove that you own the corresponding private key.


What does a Firewall mean by "connect to TCP port without your permission"? McAfee is reporting incoming network connections blocked from IPs like 198.252.206.149 (StackExchange Inc.), 54.179.231.116 (Amazon Technologies Inc.), 74.125.68.106 (Google Inc.), etc.

The ports blocked vary: e.g. 54452, 54551, 52931, 53353, 52912, 52902, 52914, 54146, 54156, 53986, 52931, 52914, 53204, 52927, 52912, etc.

These ports shouldn't be the ones used for web browsing, because I seemingly can browse "perfectly" as per usual with no anomalies.

Why am I getting these messages?

What does it mean when someone tried to connect to TCP port on my PC "without permission"?

Those messages get a D- for technical content and accuracy.  The most likely explanation is that these packets arrived late and failed the ESTABLISHED,RELATED check because the connection was already closed.

Somewhat less likely is that they actually had the CONNECT flag set in the TCP header, and your firewall is either dropping all incoming connections or the target port was closed.

Random incoming connections can occur due to malicious port scans, but also due to dynamic IP allocation giving you an address which was formerly allocated to a user of peer-to-peer/mesh transfer software, such that the address has been advertised in the mesh.  However since these are coming from sites that you do use, more likely is that the packet arrived after you already moved on to another webpage, and the browser was no longer listening for the data in question.

Unfortunately, describing the firewall action as a "block" is lacking in information as well.  There are two possible actions when an unwanted packet arrives -- DROP it, or respond with REJECT.  Rejection can take the form of an RST flag in a TCP return packet, or an ICMP "port unreachable" message.  Either way, explicit rejection leaks information about your network configuration.  At the same time, DROP can be caused by network congestion, so the remote end may retry.  So for your "friends" (legitimate communication partners), it is preferred to REJECT, while for random port scans it is definitely preferred to DROP.  And your firewall is not telling you which it is doing.


SOX Compliance - Is Running EOL Equipment Considered a Violation? Let's say I have some networking equipment that will no longer receive vulnerability patches after 2019.

This equipment makes up the spine of the company infrastructure.

Let's say it's definitely IN EVERYONE'S BEST INTEREST to go ahead and upgrade this year, but higher-ups aren't convinced that we need it.

Is it a requirement of SOX to make sure every single piece of information technology within an organization is still receiving security patches?

Is it an automatic fail if so? Or can defense in depth/compensating controls help maintain a compliant posture?

Thanks guys.

I will avoid going into detail about the nature of SOX as that info is widely available. However, I will say the following: SOX is not a control framework.

The answer is no, having EOL elements as part of Production is not a
problem (under the umbrella of SOX). Best practice/security/etc-wise
is another topic. Further, "every piece of technology" would not fall under SOX; only financially significant systems (and ancillary ones) are "in scope" (management and the audit team determines this).

Did your companies audit team bring this up? Asking as auditors don't think or communicate clearly most of the time and they may be trying to allude to something tangental.

My background: Part of my CV include 6 years as an IT Auditor for BIG 4 public accounting firms.