TL,DR: There's no way.

  a microcontroller with no hardware support for security.

No hardware support means you need to do all by software, and that means an attacker can use the same software as you. Your data must be decrypted by software, so the attacker can alter your firmware and dump all data, including the keys.

In a microcontroller with security backed by hardware, you can load the keys on a secure enclave, and have this secure component do all the decryption, encryption, and signing. Without hardware support, you cannot protect the keys.

So you have to choose between have security or keep the current microcontroller. You can't have both.


Why do mobile apps have fine-grained permissions while desktop apps don't?

There are two main reasons why smartphones have fine-grained permissions while desktop computers don't.

History.  Mainframe operating systems have a tradition of giving permissions to the user rather than to the program, and this carried over into minicomputers/workstations/desktops; the desire to maintain compatibility with existing programs limits the ability to change things.  Smartphones are a clean break with existing application ecosystems, so the opportunity existed to change the permissions model.
Smartphones are far more homogeneous than desktops, and generally don't change their hardware configuration over time.  This makes setting up the permissions system far easier.

That said, there are fine-grained permission systems for desktop operating systems.  Linux, for example, has AppArmor, SELinux, Bitfrost, and probably others.


Hidden network continually connecting that I cannot disconnect

I would suspect some kind of Antivirus program is installed locally on the computer and is managing Windows defender remotely and has also connected the Hidden Network. Most likely it doesn't mean that it's connecting you to remote servers, although it may do that as part of its operations, rather that it has installed some kind of network adapter in order to route all traffic through the program to make sure nothing bad comes in the door.

There are two places to look for more information. One is to right-click on the wifi icon in the status bar and click Open Network and Sharing Center. The other is the network adapters page, which can be accessed from the network and sharing center. If you would post a screenshot of the Network and Sharing Center window, it would be helpful, but make sure you blank out the network name before posting. The network adapters page would also be good, just make sure you blank out any network names (but not adapter names).

If you do not wish to post these screenshots, that's fine. These two windows are where I would go to find more information like you are trying to figure out. Look for a blue link next to the label Connections on the Network and Sharing Center window and click on it. That will give you the adapter info window for that specific connection.


It looks like that the debug output is made on the client side. In this case

3, RECV TLSv1 ALERT:  fatal, certificate_unknown

means that the client received an TLS alert from the server which means that the server did not like the certificate the client has send, i.e. the client certificate:

Validity: [From: Tue Aug 08 16:26:27 CDT 2017,
           To: Thu Aug 08 16:26:27 CDT 2019]
Issuer: CN=Device CA1 G2 DEV, O=groupc Inc., C=US
SerialNumber: [23415xxxxxxxxxxxxxxxxxxxxxxx]

But, the neither the debug output nor any packet capture contains information on why the server did not like the certificate. The TLS alert only contains the information certificate_unknown only without any details.

It might be that it was not issued by a CA trusted by the server for client certificate validation, that intermediate CA's are missing, that the subject is wrong etc. Maybe you can get more information about this at some logs at the server side.


In short, the answer is no, you usually can't block based on MAC address. And if you could, it would be useless. To understand why, you must know a thing or two about how the internet works.

Communication between devices is commonly done via the Ethernet protocol (wiki), and despite the source and destination being identified by IP, actual communication is done per MAC. Imagine the following network:

If the client wants to send a packet to the server, it first checks whether the server is in the same subnet. Nope, the server has a 10.x IP, and the client an 192.168.x IP. The client then sends it to his router, R1, in the hope that it will be able to forward it to the destination. The packet contains:

Source IP:       192.168.1.100     (belongs to: Client)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      01:01:01:02:02:02 (belongs to: Client)
Destination MAC: 02:01:01:02:02:02 (belongs to: R1)

Then R1 is like "Oh, that IP is somewhere on the internet". It changes the source IP to the public IP (so that the server can send a packet back), and forwards it to R2. The packet now contains:

Source IP:       172.16.1.1        (public IP from R1)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      02:01:01:02:02:02 (belongs to: R1)
Destination MAC: 03:01:01:02:02:02 (belongs to: R2)

As you can see, the destination IP doesn't change, but the MAC addresses changes every time it gets forwarded (by a router) based on which router it is forwarded to and which router it came from.

Moving forward, R2 will not tamper with any of the IPs like R1 did because it is not a NAT router (like most consumers have). R2 will merely forward the packet.

In the end, the server will only be able to see the MAC address from R3. For the communication to work, that's all it needs to know besides the original IP from R1. (When a reply packet comes back at R1, other things make sure the packet finds its way to the client.) If you want to know why not all communication is simply MAC-based, have a look at this question on serverfault.

One exception to this is when the client is inside the same LAN as the server. As I mentioned, the client first compares the IP subnet of itself and the destination. If it's the same (e.g. 192.168.1.101 and 192.168.1.44, when on a /24 subnet), the communication is based on MAC address. The client will broadcast a message on the LAN, asking for the MAC belonging to the server's IP, and then send it to that MAC. The packet will still contain the destination IP, but there is no router between the two. (There may be, but then it will be acting as a switch or hub, not as router.) But this is probably not the scenario you had in mind.

If you could determine the MAC, that would be a pretty big privacy violation. Since your MAC address arguably identifies you uniquely on the globe, advertising networks would have no problem tracking you, also without tracking cookie or any other methods.

Blocking an attacker by MAC would be the same as blocking him/her by cookie because it is controlled by the client. Currently it's almost never changed because there is almost never a reason to, but if you could determine and block an attacker by MAC, he could simply change it. An IP addresses must be globally recognized in order to be routable, but a MAC doesn't have this issue.

Also, an attacker could block clients whose MAC he knows by spoofing that MAC address and then triggering the block. Whoever really uses that MAC address would be prohibited from using the service.

Conclusion: If it were possible it would be rather ineffective and while introducing a DoS vulnerability, but since you can't make the client send the MAC along with HTTP headers or something, it's just not possible outside the same LAN.


How to avoid identity theft at key signing parties?

At a key-signing party, you show documents, you don't hand them over, nor is there an opportunity to copy them.  Someone with an eidetic memory and an evil side might be a risk.  However, eidetic memory is rare in adults.  (So is evil, happily.)

So, specific advice in answer to your question: a key-signing party should have guests known to the host, or "second order" guests, that is guests known to a guest in attendance who is himself known to the host.  Also, the host will necessarily keep a list of the guests in order for the KSP to function.  I think the risk is small.


How much damage can a malicious package do with just "npm install "?

Conceptually, installing a package permits running setup scripts which in turn could be leveraged to execute arbitrary code on the system under the privileges of the executing user (hope it wasn't root... though if it was the worst consequence is full compromise of the system). The package may also pull in other packages as dependencies which in turn bring the same level of risk.
If you're concerned, create yourself a sample VM and unpack the package to see what it does. It's uncommon (but has happened!) that signed packages from trusted sources contain malicious code, but you can't be sure until you check.


Can a SIM card be tracked without cell phone and battery?

The SIM card must be plugged into a device for it to be functional in any way. It does not contain a power supply or an antenna. As such, it'd be impossible to track a SIM card on its own.

However, once you plug it into a phone and power it on, the IMEI number of the phone and the SIM's serial number will be transmitted to the nearest cell tower(s).


Why is a fully-patched OS less important than AV?

Your thinking is correct when considering this from a technical information security perspective. Your post states It's just that I cannot see how can fully patched OS be less important here?. It's not.

The question you linked is about communication, not the technical best practices for securing an endpoint. The upvoted answer to that post is trying to address the problem of communicating to a user that an ancient, unsupported OS is a bad idea.

To a relatively skilled attacker, AV on an XP device in 2020 would be a minor hurdle/nuisance (if I were the attacker I would consider it basically a non-issue), while a fully patched endpoint with the latest OS release and the security best practices you mention (backups, local firewall, pw manager, etc.) would be a far greater challenge to own. I also agree with you placing AV last on the list.


What are the best practices for naming backend-internal WebSocket endpoints?

While I agree with the previous answer that naming should not be considered a strong security control, I would suggest that you avoid naming things in an overtly obvious manner (i.e. "ThisServerHostsMyCrownJewels.company.local" :) )

In terms of how to allow only 'S' to talk to 'E', that is a technical question for which a lot more detailed information on what platforms, versions, etc. are in use. The short answer is it could be done via traditional firewalling, or using IPTables or configurations in the WebSocket server, or perhaps more preferably a combination of two or more of these.


Can an xss vulnerability without authentication be exploited?

If the user clicking on the malicious link trusts my domain, they could be tricked into doing or accepting things that they wouldn't otherwise. But if my domain enjoys no special trust, is there still danger? The attacker has already had access to the user/victim to trick them into visiting me through the doctored link, so is my website really posing an additional danger?

The attacker doesn't necessarily have access to the user. They may have just sent a spam email with a link, or made up a fake social media profile to send them that link. Since your site seems benign enough (they may even know of the site and trust it) they may be more likely to click the link.

You're right that there is a lesser impact by way of your domain not having any secrets on it and no authentication. This is certainly true for the general users, at least. But consider that if you had, for example, a CMS admin panel on your site for managing the content or a blog, the attacker could instead trick you into clicking a malicious link and trigger XSS to get access to that panel.

While unlikely, it may also be possible for an attacker to leverage your site as a trusted domain in order to deliver a browser exploit via the XSS. A common example of this is where an attacker writes a script that reveals identifying information about someone who is browsing via the Tor browser, and tricks the user into enabling scripts on what seems like a benign and trusted domain.

  Since the reflected code appears to originate on my domain, could the attacker gain access to my intranet? I suppose in this case no trickery is needed: the attacker can run the malicious requests directly on my server, right?

If by "intranet" you mean other sites on your local LAN, not in general. Cross-origin requests are denied unless the target server allows them using a CORS header. Subdomains are also not reachable due to same origin policy unless you override this - http://foo.com cannot reach http://x.foo.com or http://y.foo.com, and http://x.foo.com can reach neither http://y.foo.com or http://foo.com without a permissive CORS policy applied by the target domain.

I'm unsure what you mean by "run the malicious requests directly on my server" - XSS results in client-side script execution, not server-side.


Is it possible to add virus to an encrypted file?

For truecrypt and Veracrypt, I believe there is nothing stopping you from modifing the file and this is likely true for all FDE solutions.

However, it would be impossible to ensure the modified file decrypts into a virus, unless they somehow trick you into encrypting the virus with the same key or otherwise gain some additional knowledge.

It could be possible to embed the virus into the file non-encrypted and get it executed if there is some critical bug in your decryption software.


How to prevent an user from tampering a request using Burp

You can't really stop a user from manipulating incoming requests. If you somehow manage to stop burp from working, an attacker can use CURL, or manipulate the request via the browser.

You could make it more complex to manipulate requests by obfuscating them, but that doesn't add any real value.

You could also use some sort of signing mechanism where a signature of the user ID must always be sent alongside the ID. But that would just move the problem to another location (when the ID and signature are requested, you still need to decide for which users to give it out).

The proper solution here is server-side validation. When receiving a request for a verification email, check if the user with the given ID has already received one and that the user who issued the request has the permission to request verification mails for the given ID.


You should never write an implementation to an existing algorithm or design an algorithm. The algorithm should be picked up from a book and implementation from a library.

Keeping the above points in mind, remember that Diffie Hellman is vulnerable to MITM attacks as there is no authentication factor involved in the protocol. For confidentiality, I would recommend using SSL.

Generate a self-signed certificate for Entity B. Entity A will have a copy of the certificate and would trust it. Entity B is authenticated. Now for the authentication of A, you can simply have a pre-shared secret which A will represent and B will verify.

You can refer the docs for DKE implementation in node.js - https://nodejs.org/api/crypto.html#crypto_diffiehellman_computesecret_otherpublickey_inputencoding_outputencoding


All ransomware implementations are different, but for the most part, the particularly stupid variants that did things like use a hard-coded key, or used easily guessable or reproducible key generation methods have been weeded out and replaced by much stronger variants.

For wannacry specifically, each infection creates a new RSA keypair on the machine being infected.  The private key from this pair is then encrypted with a public key shipped in the malware, which is part of a keypair owned by the wannacry author.

The new, infection specific public key is then used to encrypt the AES keys, which are generated using a CSPRNG, and a new AES key is generated for each file encrypted.

Presumably once you pay the ransom, the malware authors will then use their private key (the other half of the keypair to the public key hard-coded into the malware) to decrypt your private key, which the decryptor tool can then use to decrypt the AES keys, and in turn the files.


John the Ripper Brute Force not working (Windows Hash)

As best as i can figure, you are mistaken about what you expect. John finished quickly because it successfully cracked the password you requested. The rest is just error in using john --show as far as i can tell. I repeated your steps as follows:

echo "IEUser:1000:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::" > ./Desktop/hash

Then we will start a normal cracking session, which will use a default wordlist.

root@oscpre:~/Desktop# john hash -format=nt -user=IEUser
Using default input encoding: UTF-8
Rules/masks using ISO-8859-1
Loaded 1 password hash (NT [MD4 128/128 AVX 4x3])
Press 'q' or Ctrl-C to abort, almost any other key for status
password         (IEUser)
1g 0:00:00:00 DONE 2/3 (2018-01-31 14:16) 20.00g/s 18040p/s 18040c/s 18040C/s 123456..qwerty
Use the "--show" option to display all of the cracked passwords reliably
Session completed

The line password (IEUser) identifies a cracked password for user IEUser. The password is "password". We can check this by reversing the process using openssl to get the nt hash of "password".

root@oscpre:~/Desktop# printf '%s' "password" | iconv -t utf16le | openssl md4
(stdin)= 8846f7eaee8fb117ad06bdd830b7586c

We indeed see it matches our original input in hash.txt. Now we will show all cracked passwords for john in the format of nt using our pot file (the record john keeps of cracked passwords during sessions)

root@oscpre:~/Desktop# john hash --pot=../.john/john.pot -format=nt --show
IEUser:password:1000:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

1 password hash cracked, 0 left

We see IEUser listed here with the password appended before the uid.
All seems to be well?


Shall I set "RSAAuthentication yes" in sshd_config if I use only ECDSA key?

The option names are not part of the SSH protocol; they are specific to a given implementation. I suppose you are talking about OpenSSH.

As per the documentation:

RSAAuthentication
    Specifies whether pure RSA authentication is allowed. The default is
    “yes”. This option applies to protocol version 1 only.

So this does not apply to your case, since you want to use ECDSA and ECDSA keys are supported only with version 2 of the SSH protocol.

Whether clients may authenticate with keys (instead of, say, passwords) is set with the PubkeyAuthentication option. The allowed key types does not seem to be configurable, though. A client key will be accepted if it matches the public key stored in the .ssh/authorized_keys file of the target account; thus, if you want to restrict key authentication to ECDSA, you should arrange for only ECDSA public keys to appear in such files.


Someone is accessing my data, what can I do about it?

Have you considered that an Antivirus Program or a Windows App may be accessing, uploading and inspecting your files on a remote server behind your knowledge?

What you've "uncovered" using canary tokens may lead to interesting findings regarding privacy issues on Window$.
I'd start by knowing the owner of the IP address from where files are being accessed. This may give you leads about the programs accessing the files.
From there, you may seek legal counseling, just make sure that you haven't agreed to what's happening by clicking "yes, yes, yes" while installing an app or accessing a website without fully understanding the terms and agreements.

I'm not a privacy expert, but I'm positive that in some part of the Microsoft Services Agreement there's a clause allowing MSFT to upload and inspect your files on a remote server.

  "Some of them share all except the last two digits of the IP number".

Companies like GOOG, AMZN, MSFT or Dropbox own large IP address blocks. Find out the current owner of the IPA using ARIN, RIPE, LACNIC
 or APNIC.


Is it dangerous to have a credit card payment page without authentication?

The only problems I can see here is that someone could DDOS by entering random creditcard data, especially if you do not have access to the information and id at the time you accept the payment request. The service handling the payments would have tons of errors afterwards.

Still, realistically, there is no reason for this to happen unless you have someone who wants to damage you. And in this case, its probably also possible to just create an account and do the same. If you have a captcha in place, it shouldnt be a problem.

If the information and ID entered by the users is not checked before payment, there could be problems with assigning payments to the correct person.

But from a security perspective, I don't think that there is a vulnerability for a user entering his data.


Deal with number changes in a phone number based authentication/login system

Yes if the login is only based on a phone number, the new possessor of a mobile number can install the app and access the account of the old owner of that phone number.

The solution would be to add a step for entry of password/secret key (information that the user only knows)

Also the user should be able to migrate to a new phone number by using the secret key.

Digits has implemented above two changes:
- http://get.digits.com/blog/launching-voice-verification-and-change-phone-number
- https://www.digits.com/settings

One problem still remains. The old owner of the phone number can login into Digits.com and either migrate to a new number or deactivate his account.

When he deactivates, the phone number must be released so that new owners of the phone number (or the same user if he continues to own the number) can register using it. But what if user did not deactive his number? The number would be blocked for new owner of the number for using in the app


Why isn't PGP used to authenticate with keyservers?

There are a few things to take into account here.

  Why is this not required by keyservers to ensure that only the owner of the private key can upload … ?

The main problem with a malicious key is someone posing as an identity he is not allowed to use. The uploader of the key would hold the private key, so we didn't gain anything here.

On the other hand, it is sometimes useful that a third party can upload a key.

  … only the owner of the private key can modify the public key on the server?

This already happens. You can't eg. add an identity or a subkey to a key unless you have the private part of the main key. Not only the keyservers, openpgp clients would detect that such key is wrong, too.

However, it is possible for anyone to add a signature to your key. This translates to a vouch that the key belongs to whom it claims (eg. they checked your passport and it states the same name as your OpenPGP key). This is a crucial part of the PGP web of trust model (even though, if not indicated otherwise, it is educated to send the signed key to the user instead, rather than publishing the signed key directly).

  …remove the public key?

To a point, it already does so. Note that the keyservers form a distributed system, with the many servers syncing their different keys. Thus, if a keyserver completely forgot about a deleted key, it would be readded a few hours later when syncing with another server. Thus, what we need is a deleted flag that only the key owner can set.

This already exists, with the name of revocation certificate.

-

Note also that the goal of the keyservers is to hold many keys (so you can find the one you need), not having trusted keys or providing any kind of insurance over its contents. You are expected to use the Web of Trust for that.

A closed keyserver that functions more similarly to what you propose is the debian one: https://keyring.debian.org/ It does so by adding a human into the process (the Debian Account Managers) in order to perform some steps (most importantly, the upload of new keys).


Schemes/ Mechanisms that could provide one time decryption?

There is no way to do this - this is a subset of what DRM schemes attempt to do.

If an end user can decrypt something once to see it, they can see it again. Any of the following may be possible:

first take a copy and decrypt that
copy the screen
edit the application

The only way you could get close would be to have total control over the hardware and software, so you could delete once it has been shown, but even then, someone could use a camera to take pictures of the screen etc.

So, I'd like instead to ask what you intend to use such a scheme for - as there are ways to have the same effect in many scenarios.


Repudiation in Copyright Infringement (BitTorrent)

As far as legally equating an IP address to a person, that's gone both ways in the USA.  The USA Supreme court hasn't ruled, so anything is possible. I suppose that in the Axiomatic System of the US Legal system, you could equate an IP address and a person, but in the Real World, you are correct. Such identification is going to turn out false in some cases. For instance, some people have spoofed the system, causing their printers to be implicated in file sharing.

Just as an aside, I think it's a bad idea to put things that come up false, or can be made to come up false on demand, into an axiomatic system. Theoretically, that lets you prove any theorem of the axiomatic system. Disaster for the US legal system.


Why aren't there FIPS level 4 devices on the market?

When based on a standard, especially those as stringent as FIPS 140-2, you have to go through the following processes (which are time consuming and expensive):

Design
Testing
Certification

If you take a look at the NIST Implementation Guide for FIPS PUB 140-2, along with the other documents, you can search for the Level 4 implementation which detail that this is designed to be tamper-proof.

It is considered "overkill" for most businesses and even personal use because it protects against "drilling, milling, cutting, burning, melting, grinding or dissolving the epoxy or potting material, in order to gain access to the underlying circuitry." It is also meant to protect against environmental factors. This is your doomsday USB standard, where you under no circumstances can lose or leak the data.

It is a very aggressive set of requirements that is very likely not very economical if you intend to sell it to a consumer, for the same reason a crash-proof car is feasible, but your average person is not willing to pay the price or deal with the complexities involved.

This explains why government entities can have this kind of technology:

They are not a profit seeking entity, technically.
They are not restricted by the requirements of making a product marketable, they are their own customer (and other governments, too).
They have schools, renowned labs, and dedicated facilities at their beck and call to build "cool" things in the name of safety, public service, defense, or what have you.

Bear in mind that building cryptographic devices, especially at the hardware level, is not a fool's errand.


How to defend against a Spoofed-IP Blacklist DOS attack?

According to several of these answers:

https://serverfault.com/questions/381393/can-the-ip-address-for-an-http-request-be-spoofed

It is really unlikely that you could indeed spoof the IP address and send a full HTTP request to a server. TCP requires a three-way handshake, which means sending one packet back to the sender and expecting a very specific answer back (with a number that is expected to be random, 10+ years ago, that number would just be incremented so it was possible to more or less guess the next number and thus send a "reply"--second request really--with the data and thus the HTTP request itself).

With that in mind, blocking an IP address is a good way to prevent wasting bandwidth to satisfy a robot thirst in an attempt to log in an account. Many systems offer this capability and most, like yours, do it temporarily. Actually, I generally set mine up to block that account for 1 whole day because I've seen many attacks lasting at least that long. That being said, my websites are not like Facebook or Twitter where people come back several times a day pretty much every day... So it will depend on your business model, who uses your systems, how much, how often they need to log in or log back in, etc.


VPN is a generic term encompassing many approaches and technologies.  IPSec is one approach to encrypting VPN traffic and is used in L2TP and some other VPN protocols.  Cisco OpenConnect VPNs use DTLS instead.   OpenVPN uses SSL/TLS.


There is one caveat when using X-Frame-Options header: it only checks the top level frame. This means that if you have nested frames, i.e. frames within frames, it is still possible for another origin to include a site with a X-Frame-Options: SAMEORIGIN header.

In this regard the header Content-Security-Policy: frame-ancestors 'self' is better, because it checks all frame ancestors.


Should I be concerned about a very slow dictionary attack?

Just block them by changing time interval in your jail rule.

bantime  = 10800 ;3 hours
findtime  = 86400 ;1 day
maxretry = 5

If an attacker fails 5 times in a day, he will be blocked for 3 hours or you can increase that number according to your wish.

Prevent as much as possible, before it will be to late.


Yes, your interpretation is correct.

Now, if you suspect that the drive might have been compromised while it was not password protected, you could do a secure erase, which essentially means generating a new DEK, rendering all the previous data unreadable.
By "compromised" I mean that the DEK, not being encrypted by a password, was somehow extracted from the drive, and the attacker could use it later to decrypt the drive's contents even after you set a password (store the DEK encrypted on the drive, but still use the same DEK). This kind of attack might not be easy, as you can imagine.

So depending on the sensitivity of the data, and the trustworthiness of the drive, you should choose whether to just set an encryption password ("do it in-place") or do a secure erase (generate new DEK), set a password (encrypt the DEK), and then copy over your data from a backup.


Anyone able to use your printer is a vulnerability.  This is a resource that should not be exposed to public networks.   I suspect that "scanproxy.net" is well... scanning for proxies.   Its likely that they connected to an open port and tried to proxy a GET request for http://www.scanproxy.net:80/p-900.htm,  but instead this was interpreted as data to be printed.

Conduct a full port scan (0-65535) of your network range from an external node. Close any unnecessary ports.


Header opening a PDF file, can someone hack a website from there?

There's no security vulnerability directly in your code.

As an aside, I assume you're using parameterized queries via MySQLi or PDO when doing database calls? If not, you're highly likely to be vulnerable to SQL injection in other parts of your site.


Segregating Offline Server and Internet Connection in one pc

Any malware you get on your workstation can then do whatever you could do to the server, including copying any files, saving credentials, etc.  Additionally, while you're connected to the internet, the malware could essentially proxy attacker traffic to the server.

The setup you've described is arguably more secure if your client is not compromised.  Your server is essentially segregated from the internet, so reduces its vulnerability to attack.  Of course, you're also adding complexity: how will you install new software, patches, etc.?  You'll need some way to get that traffic to/from the internet.


Good way to make a secure token for logged out users

Yes, if the "salt" is a secret word, it is possible for a user to calculate the hash by running a simple dictionary attack until they come up with the correct hash for their adid.

It's not clear to me why you need a token at all.  Is this just for some logged out users rather than all logged out users?

Regardless, if you do need to provide the user with a token that they can't duplicate, it needs to have a message authentication code.  If it's not secret (which it doesn't seem to be, since you said the adid which the user already knows will suffice) then use a MAC algorithm such as HMAC to ensure it can't be tampered with or forged.


Is there a way to sniff a "mousejack" attack?

If I understand this issue correctly, mouse movements are sent unencrypted by design, and keystrokes are sent encrypted by design, however the receiver also accepts unencrypted (and unauthenticated) keystrokes as well, allowing an attacker to inject them?

Regarding detecting unencrypted mouse movements, I would say there is no easy way to detect such an attack. It simply appears to your computer as regular instructions for your mouse. Imagine you were blind, you could not move or speak, and the only sense you had was hearing. Now it gets worse. Not only are you only able to hear, but you aren't able to differentiate between differentiate between voices. That's what a wireless mouse receiver is like. It has no way of detecting such an attack because the fake signal is identical, for all intents and purposes, to the legitimate signal.

As for unencrypted keystrokes, that's a different story. Because keystrokes are not meant to be unencrypted, the receipt of an unencrypted keystroke is an anomaly. If you connect a Bluetooth device to your computer which can capture arbitrary Bluetooth packets, you should be able to detect when unencrypted keystrokes are transmitted. You would have to find out what the format is, how to detect when the packet is unencrypted, and then how to detect if the payload message contains a keystroke. If it is, then you should have your computer immediately disconnect the keyboard and mouse device and alert you so you can take action. I know of no way to already do this, but there are ample resources to learn how to.

Note that Bluetooth is historically not the most secure protocol, so even if this "vulnerability" is fixed, using a Bluetooth connected mouse and keyboard is rather foolish. PS/2 is low power, entirely interrupt-based so the CPU isn't being woken up thousands of times a second. USB is cheap, the cords reach as long as you want, and if you know how to manage your wires, they will never get in the way. Using wireless peripherals is asking for trouble.


unravelling of https sessions by corporate web proxies?

While I can't say if it it is exactly true in your situation, it is definitely possible and probably likely given your IT guy said it is.

A guess would be all machines in your network have a trusted certificate installed that allows your corporate proxy to MitM your TLS connections. Essentially, you are connecting to the proxy securely and since you trust the proxy's certificate it doesn't alert you. The proxy then connects to the outside normally.

Reasons this is useful to the company are substantial. They can now be aware of ALL traffic passing through their network and it makes it easier to spot malicious activity. That or otherwise unauthorized activity (porn, drugs, etc.).

This question comes up a lot in regards to privacy. Just remember the company OWNS the network. Don't browse personally on it.


Yes, add a captcha to all exposed forms or contact pages on the internet to prevent spam like this


Is proper documentation on .xef files available anywhere?

According to wikipedia:

  Packing of ACE files is licensed as proprietary information and only available through WinACE, while Unpacking of ACE files is supported by a number of third-party archivers. However, virtually all of them (the ones that support ACE 2.x format) do this by using the proprietary "Unace.dll" from e-merge GmbH.

In the WinACE site you can read that using that .DLL you have:

  The downloadable distribution of UnACE.DLL contains the 32bit .DLL, a list of function calls as well as some function prototypes, structures and constants to include when using the .DLL.

So, perhaps using it you can retrieve those informations.


How to prevent cross site scripting in wordpress?

How do I prevent the cross site scripting?

Perform input validation and output encoding. Only allow characters that you expect, for example if you only expect digits, the back-end should not process regular characters.

Sometimes you expect a specific length, if the back-end detects it's either smaller or larger, do not process it.

Same goes for special characters, if you request a first name, don't allow special characters such as "<", ">", "$" etc.

  Should I put validation in front end view (HTML / CSS / JS) or on back end (PHP / Wordpress)?

Validation from a security perspective is always performed server side. Client side validation is only done for user experience.


What's the worst security issue what can happen by using eval() in Android WebView?

meh. eval might be scary or downright dangerous in the hands of the naive, but script tags are actually worse from a capability perspective, yet needed. Hybrid apps need scripts to run and can't do anything without them. Just like in a normal webapp, content will be fetched from a server, and some of that content needs to execute to drive the app.

The developers could put most/all of the JS into the client app instead of loading it from the server, but that gets stale quickly, or gets annoying by posing constant updates, while changing a server response is instant and invisible to the user. If the app uses a modular system and has a formal communication mechanism in place, it probably makes sense to deliver code using the same "pipeline to home" as the data. This offers the opportunity to sign, validate, restrict, isolate, and reject tampered code.

In terms of security issues, consider that all apps are a security issue. The app itself can do a LOT more than sandboxed JS running in a webview can. There's also ways to restrict capabilities when evaluating manually-fetched code, aside from code inspection, by running in a different context, like those in node.js, webworkers, empty frames, official (ES20xx) modules, etc.

While I obviously don't know the detail of the app's code-handling, I wouldn't assume that the fetched code runs top-level (indirect eval) with access to "everything". Nor would I assume that user-created-content is accidentally shipped inside these response fields. Nor would I assume that the OS's web-view sandbox is being broken out of, or that the OS's app isolation measures are failing. Nor would I assume the app even has enough permissions to stitch all the requisite mistakes together in a way that permits anything more sinister than a run of the mill money-making app that doesn't use hybrid views. The "worst that can happen" (omitting zero-days) is whatever the apps permissions allow, same as always.

In short; your observations reveal how this app works, not that it's doing anything inherently misguided or especially risky.


Are those animated video thumbnails generate the same DNS from actual videos?

Now, here’s the real question. When you click the thumbnail to watch a video on a new page. Of course, you would be given a new DNS footprint because you have opened a new page.

Probably not. DNS is cached extensively. YouTube seems to have TTL of 300s, which means that responses are cached for 300 seconds.

  To put it simply, I don’t my DNS footprint to show I watched that actual video just because I “previewed them on thumbnails without clicking them.

DNS does not show what you watched. It doesn't show the URL. It shows host names, not URLs. It does not say anything about what you loaded.

Furthermore you should remember that modern web applications like YouTube does not execute requests only when you click, but do so more or less continuously in the background.

  I don’t want my ISP to interpret that I clicked 100 videos just because I “previewed” them on these uncontrollable thumbnails. Am I worry to much?

If I were a ISP, and wanted to detect amount of videos you were watching, DNS wouldn't even be part of the equation. But why would an ISP want to do this anyway?


What techniques do web services use to identify password theft?

In addition to the verification methods you've provided, Web services keep track of users using the following methods. Usually a failure in any of these services can cause a site to block access or lock an account.

Cookies

These are text files that a website will send to your browser when you access a site or service. These files contain information specified by the site for use in things like authentication and recognition. Sometimes they store preferences, other times they may store things like last access time or last IP address. Often this information can be encrypted or encoded in a non-readable method. When a user visits a site, the information on the computer (if it exists) is compared with what they have on file.

Cookies are also useful in catching failed attempts. When a person (UserB) tries to login to a site as UserA the site can present them with a cookie for the username they're trying to use and another one containing the number of logins they've attempted. When they login as UserB and use their own account at a later time, the site can collect the cookies for the previous attempts and then cross-check their records to see if UserA is related to them or aware of the attempt.

Sessions

When a user accesses a web server they open something called a session. During the session, the browser and the server exchange information in the form of variables and cookies. This information will exist as long as the session is open. Sessions can have a specific timeframe where they are active and they can also be destroyed when someone leaves a website or closes their browser. When a person tries to access a site from a second device using the same logins this will open a new session. Some websites are aware of this and will say something like "You're accessing your site from two locations. If you are NOT accessing this site from multiple locations please contact customer service."

Database Comparison (Location, Device, Activity, Habits)

Some web applications store information about a user, their habits in terms of spending (banks and credit card companies do this), frequency in access, and IP geolocation. When a user accesses a site their stored profile is compared with their current session to see if the user's behavior fits the pattern on record (Location, Device, Duration of access, Etc). An example might be someone logging in from another location where they have never logged in before.

Two-Step Authentication or Verification

Some sites like Google may require you to use an authentication app installed on a mobile device that you have been previously authenticated on or they may require you to check your e-mail account to get a one-time password. This is called two-step or two-stage authentication or verification. When you attempt to log into the site from a new machine or a machine that doesn't have an active session or existing cookie, you'll have to provide information from the second device (usually a cell phone or e-mail) to prove that you are the person who originally setup the account. Sometimes this is also done in the form of an SMS text message.

Timers and Real User Verification

Some sites will use a real user verification scheme like a CAPTCHA to make sure that a user is really a person and not a bot. Websites like banks and some stock photography sites implement other schemes to make sure you're not performing too many tasks at once when you have your session open. If you're reacting more quickly than a human user they may close your session. Additionally they may close your session due to inactivity because they try not to assume that a delay in access means the same user on the same terminal.

Preshared Key Verification

Most websites will provide a user with a password. The user is requested to provide this password when they access the site again.

Challenge and Response

Some sites request information in addition to a password in the form of a challenge and response phrase where a user can authenticate themselves. "Where do you go to School?" "Where were you born?" the answers to these sort of questions are typically not known outside of a user's circle of friends and family. The reason these questions aren't the main questions for authentication are because of things like unfiltered social media where someone can do a web search and find the answers by reading a profile.


Robots.txt is not, in any way, supposed to secure your site. The only purpose of the robots.txt file is to inform polite search engine bots what areas do not contain interesting information.

If you have sensitive areas in your robots.txt file, then you seriously need to review the architecture of your site. No sensitive directories should ever be accessible to the public in any way. In fact, anything exposed to the public should be secured, whether it is visible or not.


HTTPS vs. HTTP - Is there a security reason for HTTPS for a site that only does Facebook login?

My general guidance to websites is to just build new sites on SSL, plain and simple. Make your life simpler.

Keep in mind that if you don't, all traffic between your users and your servers can be intercepted and manipulated. So, for example, if you were running a forum, I could intercept cookies and post to the forum as your users. Forum data is probably not the end of the world and has nothing "private" associated with it. But having users impersonating other users is just icky.

Using news as another example, as you pointed out, probably nothing sensitive. But if you have a profile feature, then others could see the news I have signed up for. And potentially manipulate it. It's a data leak sort of thing. Again, not the end of the universe, but icky.

None of these problems matter until one day you wake up and they suddenly matter (like if you get big and someone writes a FF extension to make it as simple as "follow these 3 easy steps").

Your life will be simpler if you start SSL and never look back.


Risks of building an API without authentication?

"Good security practice" is to follow Kerckhoffs' Principle:

  One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.

Not following Kerckhoffs' principle means you're doing security through obscurity. A quick google will show you what the community thinks of that.

Your question:

  And how would they know what data/arguments they need to send in order to make bad use of any of the API functions?

Maybe through a brute-force crawler. Maybe they somehow get access to your WSDL or Swagger files containing the full description of the API. Maybe they get access to your client app or SDK and reverse-engineer the API. Maybe they sniff traffic and observe people using your API. Maybe other methods.

It's clearly up to you whether adding auth is within the scope of your project, but having APIs that serve or accept sensitive data with no auth is very much bad practice. Better yet is to have access control on top of auth to control who can view / set which data.


In what ways does Full or Partial Homomorphic Encryption benefit the cloud?

Homomorphic encryption is about encryption schemes which allow computing with encrypted value without decrypting them. For instance, given E(a) and E(b) (the encryption of a and b), you can compute E(a+b) without knowing a, b nor the decryption key.

Homomorphic encryption schemes are very useful in voting schemes, with the following structure: voters encrypt their votes, the homomorphic property is used to add all votes together, and the result is decrypted (with group decryption by a set of authorities who need to gather together, in a very public way, to perform a decryption). There are several homomorphic encryption schemes, some have been known for decades (e.g. El Gamal). They are efficient, and secure (as secure as asymmetric encryption can be). Note that homomorphic encryption solves the question of anonymous tallying, but that's only a small part of a proper voting scheme (e.g. the voter must also prove that he encrypted a 0 or a 1, not a 20 -- otherwise, he could get 20 votes). Homomorphic encryption can also be used in digital cash systems, there again in order to ensure anonymity or some other properties.

Fully homomorphic encryption is a term which was coined when were first found encryption schemes which preserved two algebraic operations in a ring structure: namely, given E(a) and E(b), you can compute E(a+b) and E(ab). It turns out that with those two operations, you can compute just about everything. This is where the "cloud" gets into the picture: the cloud is powerful, but not trustworthy; hence, you could encrypt your data, send it to the cloud which performs the computation you want to do, and then decrypt the result.

Offloading computations to the cloud is, right now, a pure fantasy. The most efficient fully homomorphic encryption schemes currently known, based on a scheme by Gentry (published in 2009), are still very expensive, and the "arbitrary computation" part involves representing the computation as a circuit where each logic gate is emulated through its own homomorphic encryption. We are not talking about a 10x slowdown here; rather, we are talking about the whole Amazon EC2 cloud not being able, in a day, to perform homomorphically a computation which would take one second on a single iPhone. So while this is very interesting on a theoretical point of view, it will take a while before anything applicable in practice is discovered. Also, 2009 is quite recent; traditionally, we wait for at least 5 to 10 years before declaring that an asymmetric encryption scheme is "secure".


DMARC/SPF/DKIM - forward quarantine emails to a separate email address

A quick search turns up DMARC Failure Reports.

  The strategy we recommend is to first publish a simple record in
  monitor mode (i.e. “p=none”) just to get aggregate reports.

_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"

  Study the aggregate reports, understand your mail infrastructure,
  understand what would happen if you change the policy to reject,
  especially how many failure reports you are likely to receive. Once
  you are confident, add the “ruf=” tag pointing to a different mailbox
  than the rua= tag points to. If you get too many failure reports, this
  will not fill up the aggregate report mailbox, so you can keep your
  statistics running.

_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"

Note the warning at the top of the section though regarding whether you actually want to do this:

  Not until you have read this answer and made sure you are ready to receive a LOT of messages...

Edit: I misread the wiki slightly, it looks like RUF reports can include the entire email, but they won't necessarily.

It's obviously up to the server validating DKIM and SPF to decide what to do in the case of failure, DMARC is essentially asking servers "could you please treat validation failures a certain way", and RUF is asking "if an email fails validation, could you please tell me why?", but it's quite possible some servers just aren't bothering to give you a report, or that the report doesn't include everything you want it to. If they want to ignore your request there's not much you can do.


The problem with ECDSA is not related to what is signed with ECDSA; the need for a thoroughly random k parameter for each signature applies regardless of whether the signature is for a crypto-currency or an email or a digital certificate or whatever.

ECDSA, as a digital signature scheme, is quite reasonable. It is efficient (faster than RSA), its signature are short (shorter than RSA), it has been studied for quite a long time. The need for randomness is an important issue, but solutions exist. In any case, it can be viewed as an implementation issue; and modern computers (including smartphones) have access to all the needed randomness. If only the code is written properly.


Is a One Time Password Scheme based on Diceware viable and secure?

The problem is that a random number generator is not cryptographically secure.  Someone could look at the progression of passwords and potentially work backward through the algorithm to determine the seed being used.  At this point, your key would be broken.

The method you describe is actually very similar to the way most two factor token devices work however.  Basically, they store an encryption key securely.  They then use that encryption key to encrypt a timestamp based on an internal clock.  The server also knows the key and knows what the encrypted value should be.  They then hash it down to a value that can be easily entered by the user.  If both values match, you are given access.

Drift correction for the token's clock is done by looking for slow drift and adjusting the time offset for the token on the server.  (For example, if you consistently start putting in codes that are about to be valid, then it knows that the clock on the token is running fast and can adjust accordingly.

The server also stores the most recently used timestamp and will not accept any codes that precede it.  (Though they wouldn't be accepted outside about a 1 minute window anyway, but this is to prevent a quick replay after making it appear a code was denied.)


Which of the following studies is the most important for a penetration tester?

Which of these programs is the fundament for a penetration tester ?

It depends what type of penetration tester but in general - All.

As a penetration tester it is your job to know all about the whole stack from the down up.

But if I would have to choose one to get started on I think that studying IT Administrator will provide you with a little of everything allowing you to get a basic concept of what you will be working with as a penetration tester.


TLS provides effective confidentiality and integrity for communications.  Unless you must prevent TCP/IP header information leaking, an IPSec or similar VPN is likely overkill.  Even then the TCP/IP headers in packets for the IPSec tunnel from the Android device's public IP to your services VPN endpoint public IP would still be visible so TLS is still likely better.

If you want users to have anonymity in the presence of hostile snoopers or totalitarian censorship regimes then you may need something like FreeNet or the CE|NO GUI built on it.


Is it safe to use the same Google account to communicate with users and for AdSense and analytics?

There is no problem using the same email (other then spam), as long as you don't distribute the login credentials. If your site needs credentials for the automated mails, it would be better to have separate account just for that, so that if your site is breached, your main gmail account is not.


How do I find a PKI smart card reader/writer for development (Microsoft .NET)

Have you ever built any PKI infrastructure before?  The technical details are only a part of the story with PKI, some of the most important details are in the policies and procedures generated to support this system.

I can understand wanting to dive in and experience the technical aspect.  I would recommend creating at least a two-tiered PKI with something like OpenSSL or even experimenting with GPG, since they are low barrier to entry.  If you are really wanted to gain more experience with the Microsoft stack the Windows Server 2008 PKI and Certificate Security were an invaluable resource for me when I setup my first Windows based PKI.

The Federal Public Key Infrastructure guidelines are a great exercise in seeing how the policy side should look from a sideways glance.  WARNING Do not try to emulate these too closely as it is turtles all the way down.

Once you understand how it is all put together you are really setting yourself up for steamrolling smart cards.  Personally, I've always wanted to try to the ones which keep a portion of the application on the card to see how it actually works performance wise in a real environment.

That aside, I'm just a guy on the Internet and I would encourage you to follow your passion.  Just keep in mind, there is a reason why PKI deployments command a high price.


How can I prevent modsecurity from logging binary data

You can use @validateByteRange to look for those characters that may cause you issues to drop the request body C part from the auditlog but do that after doing your basic filtering (OWASP CRS + positive filtering) so you can make sure you are not dropping important logs.

SecRule REQUEST_BODY|ARGS "@validateByteRange 9,10,13,32-126,128-255" \
    "id:666,\
    phase:2,\
    pass,\
    t:none,t:urlDecodeUni,\
    msg:'Invalid character in request (non printable characters) dropping request body',\
    severity:'INFO',\
    setvar:'tx.msg=%{rule.msg}',\
    ctl:auditLogParts=-C"


How can we eliminate passwords given the problems with biometric authentication?

First of all, let's keep in mind that vendors of biometric solutions have a vested interest in badmouthing passwords to promote their own products and services. There is money at stake. They have something to sell to you, but that doesn't mean you will be better off after purchasing their stuff. So one should not take those claims from vendors at face value.

Moreover, and perhaps I have a fundamental misunderstanding of how
biometric data is stored, but what if this information is breached?
Changing a password may be tedious and expensive, but at least it can
be changed. I'm uncertain how biometric authentication address this
problem--as I cannot change my face, iris, fingerprint, and etc.--or
if it needs to address this problem at all.

This is precisely the biggest problem with biometric. The compromised 'tokens' cannot be revoked. Breaches have already happened on a large scale. A devastating occurrence that will have consequences for many years to come is the OPM data breach.
Faces cannot be protected. They literally are public knowledge. Lots of people have their face on the Internet nowadays. Fingerprints can be seized off a glass. These are not secrets.
On top of that the collection of biometric data is a formidable enabler for the mass surveillance of individuals. Even the most democratic governments cannot be trusted. Technology also changes the nature of government and social interactions - not always in a good way.
We have to consider the trade-offs: what do you have to gain vs what could you possibly lose. Is the convenience worth the risk ? Not everyone is convinced.
So it is not just a technical issue but a societal issue that has enormous implications. Hint: China is the benchmark.
The false or negative positives rate is also a problem. Some people cannot be enrolled because of their physical characteristics. A password is unambiguous. You either know it or you don't. Biometrics = calculation of probability.
Relying on biometrics alone is not wise for critical applications. Hence the emergence of multi-factor authentication.
As an example 3-factor authentication would be:

something you have: for example a smart card
something you are: this is where biometrics comes into play
something you know: for example a password

It would be objective to say that biometrics are gaining momentum in some markets/applications, without eliminating passwords altogether. It does not have to be a zero-sum game.


In a "card not present" transaction, is the credit card number, expiry date & CVV considered as a "What you have" or a "What you know"?

A requirement for "what you have" based authentication is that ownership can be clearly assigned to a single specific entity. This specifically means that this information/device can not be (easily) cloned and that access to the information requires access to the original device.

But credit number, CVV & expiry date are static information which can be easily cloned. Once you've entered these pieces of information somewhere they are not any longer what only you have. Thus they cannot be used as "what (only) you have" authentication. One-time passwords (OTP) are different. As the name suggests these are one time and cannot be reused, so access to a specific already used OTP is of no use for the attacker. Instead one needs to have access to the device generating the OTP, i.e. "what (only) you have".

In the case of the credit card: when you pay or get money by using the Chip and Pin functionality (EMV) you use the uncloneable part of the card, i.e. the "what only you have" part. If instead you use only the old magnetic stripe or the information written on the card (number, CVV...) you deal with easily cloneable information. This means this information is "what you have and others might have too" and thus can not be used to prove ownership of the card.


Work from home, remote monitoring software, vpn, privacy

The screen and KVM are irrelevant. The software is on your work computer. That computer and it's output will be monitored. If you switch to the other laptop, the monitoring will still record the old one's screen. There is no actual problem in your case.


How can a connection be secure, if somebody observes it from the beginning?

A connection can be secure using asymmetric cryptography, even if somebody observes it from the beginning.

Why?

Asymmetric cryptography is a class of cryptographic algorithms which requires two separate keys, one of which is secret and one of which is public.

The public key is used to encrypt plaintext or to verify a digital signature; whereas the private key is used to decrypt ciphertext or to create a digital signature. The term "asymmetric" stems from the use of different keys to perform these opposite functions, each the inverse of the other – as contrasted with conventional ("symmetric") cryptography which relies on the same key to perform both.

So if the attacker steals the public key, he would not be able to decrypt the ciphertext, because he does not have the private key, which no one else should have access to.

As pointed by @Ullrich, you can find more useful informations on How does SSL/TLS work?.

Other nice article: How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?


If a website allows another person to get a list of the site's users passwords, how likely is it that the passwords are stored in cleartext?

No, you're not paranoid. The chances are pretty high that passwords are stored as plaintext in the database (it's the most obvious explanation). Some estimations say that 30% of websites store (or have stored) their users' passwords in plaintext. Examples include Reddit.com or RockYou.com. It's typically only after a serious breach occurs that the password storage procedures are put to the test.

Often sites that store passwords in plaintext will offer you a possibility to resend you the old password once you forgot it. That pretty much proves this insecure practice.

There is a possibility that the passwords are stored encrypted and were decrypted for the report, but it's a rare practice. Even if the passwords are encrypted there will always be a problem of key storage as the application most likely would need access to the decryption key for authenticating its users.

Of course the proper thing to do for the application is to salt and hash the passwords.


What is the purpose of forcing people to provide "security questions" and answers to them?

You are essentially correct, they don't really "increase security." They are there to (nominally) increase user convenience in case a password reset is needed, at a cost to over-all security.

If you forget your password, many password reset mechanisms require you to answer these questions as a secondary form of proving it is you. these are a hold over from the days before most of this information was easily available, and assumed to be relatively secret.

If forced to use such a system, and you are concerned about security, you can either enter random garbage even you won't know, and take responsibility that you will never be able to use their password reset feature, but neither will a bad guy. Or, enter some other password or token you will remember, but is not the answer to the question.

Don't use anything sensitive for these fields, as you can assume that unlike passwords, they won't be hashed, and may be visible to Customer Service reps trying to verify you over the phone.

For best practice guidance, NIST declared that security questions should not ask users for specific information such as “What is the name of your pet” in the Digital Authentication Guideline publication SP-800-63B (section 5.1.1.2).

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret


Is LXD virtualization as isolated and secure as KVM virtual machines?

LXD is at the time of the answer1 a container technology. It uses Linux namespaces, i.e. the processes inside an LXD container run inside the same kernel as the host but have separated network, users, file system etc. LXD can thus only run Linux processes.
KVM is instead a virtual machine technology. It runs a full operating system inside some virtualized hardware. This OS can be Linux but can also be Windows or other OS. The processes then run inside this new OS on the virtualized hardware.
KVM thus provides more separation - both between a VPS and the host and also between different VPS on the same host. A bug in the complex Linux kernel might allow for a LXD processes to break out of the separation. With KVM instead a bug in the far less complex hardware virtualization layer is needed to escape from the virtual machine. Note that both kind of bugs have existed in the past.

... doesn’t make sense from a privacy perspective.

The differences between these technologies is not about privacy. None of these technologies actually provide privacy by their own.

1 With version 4.0 LXD can also be used to manage virtual machines in addition to containers, i.e. it can make use of KVM+qemu. This answer here is about the original LXD which was only used to manage LXC containers. So this answer is basically comparing container with VM.


How would one crack a weak but unknown encryption protocol?

Assume I'm an attacker, and I am faced with an weak-but-unknown encryption algorithm developed by "Dave". How would I crack it? I wouldn't even know where to begin. It would be a seemingly meaningless string of characters.

That's correct, you wouldn't. Here's some encrypted data (4587556841584465455874588). Got a clue what that means? Absolutely not.

However, you're missing the core, fundamental most integrally important central pillar key to the universe that holds cryptography together. The idea is simple:

the key is everything

That's it. That's the bit you have to protect. The bit you must guard with your life and hope nobody is going to hit you with a hammer until you tell them what it is.

On this basis, you must assume that your algorithim can be read by the attacker. They know how it works. They can document its process. If there are any weaknesses, they'll find them. And they'll exploit them. Like that angry CIA Dad from Taken.

This, it turns out, is less of an assumption and more of the practical case in use. Dave, the home brew cryptographer, wants to include an encryption algorithm in his program. Deciding to eschew all the testing and design work cryptographers have done for him for free over the years, he writes something involving the odd xor, compiles his program and helpfully gives it to friends.

That algorithm is now in their hands. Game over.

Now, you might ask "can't I just keep the algorithm secret? That'll work, right?" Oh Dave, plz stop. Nonono. The problem with secret algorithms is that they're much more likely to be stolen . After all, the key is different for each user (actually, this is not a requirement, but, let's just assume it is for simplicity) but the algorithm remains unchanged. So you only need one of your implementations to be exposed to an attacker and it is game over again.

Edit: Ok, in response to the OP's updated question. Let us assume for a moment that the algorithm is totally unknown. Each of the two participants in an encrypted conversation have perfect security of their algorithm implementation.

In this case, you've got data to analyse. You could do any one of the following:

Analyze for frequently known letters. This is how you'd break a typical caesar-shift cipher.
Attempt to guess the length of the key. With this information, you can move into looking for repeated ciphertext blocks which may correspond to the same plaintext.
Attempt index of coincidence and other such measures used to break the vigenere cipher, since many polyalphabetic ciphers are (possibly) just variants of this.
Watch for patterns. Any pattern might give you the key.
Look for any other clues. Do the lengths correspond to a certain measure, are they for example multiples of a certain value such as a byte boundary and so are (possibly) padded?
Attempt to analyze with one of the symmetric cipher cryptanalysis techniques. These rely on knowing the algorithm in many cases, so may not apply here.
If you believe the the data in question represents a key exchange, you can try one of the many techniques for breaking public key algorithms.

The fact is that a short piece of data from an unknown algorithm could well be undecryptable. However, this does not mean you should rely on this being the case. The more data a cryptanalyst can recover, the more likely they are to break your algorithm. You probably don't know without serious cryptanalysis what that boundary is - for example, it is reasonable to assume that one could bruteforce a caeser-cipher algorithm for three letter words, since there are few that make sense.

You are up against re-use problems too. In WWII, the Engima overcame this problem by having programmable settings for their secret algorithm, but this was broken too.

There is also the human element of cryptography to consider. I realise the label on the tin says "use once, do not digest" etc, but humans are humans and will likely use twice, three times etc. Any such behaviour plays into the hands of the cryptanalyst.


Secure sensitive data but still allow admin access

i am not a pro but im working on a problem like this and i think you can use encryption with RSA and use a public key to encrypt data and then save it on database and when admin wants to read data , with a private key start to decrypt with a safe private key. and you may do this on top of hashing data with strong salts. obviousley you should keep private keys in a safe place.


wget: what security issues am I not considering?

There are several questions in here. You are asking how to avoid detection, how to avoid attribution, and how to avoid exploitation. Though you did elaborate on your goals, I still don't know your specific threat model. I can guess a few likely possibilities, and my answer is based on the best understanding I have on what you want to accomplish. I will edit my answer in response to question updates.
Your goals

avoid attracting the attention of target website admin, others.

Whether or not this occurs depends on how the target website is configured. Various spiders can be fingerprinted, so even if they are using a common user agent, they are still displaying some behavior unique to them. For example, the order in which client HTTP headers are sent, and even their case. There is no way to prevent a website administrator from knowing that you are using wget rather than a regular web browser if they are determined to do so or have software designed for such detection. Your techniques are probably sufficient to avoid tripping over a typical IDS, though.

be untraceable to my actual IP.

Since you said you were using torsocks, I think I should add some information on how it works. The way torsocks provides a Tor connection is by using LD_PRELOAD to hook network-related functions. When these functions are called, the function from the torsocks library is instead executed, and it redirects the connections to a SOCKS5 proxy. This is useful for applications which do not support the SOCKS protocol, but it can easily be bypassed, either accidentally or maliciously. If an application uses raw assembly to invoke a syscall directly, it will bypass torsocks. As the latest version of wget uses libc networking functions rather than invoking syscalls directly, this should not be a problem for it. Hypothetically, though, a compromised wget could easily bypass torsocks. The solution is to run it under a user where all non-Tor traffic is denied. This is possible by running a system instance of Tor under its own user (which is usually the default), and using iptables to block all outgoing connections from UIDs other than that of the Tor process.
I assume you are also aware of traffic analysis attacks which affect Tor and any other low-latency anonymity network. Judging by your goals, this is probably not an issue as a very large AS-level adversary is required to pull this off with any accuracy.

avoid leaving traces that would enable a web admin or whomever to detect that different jobs are executed by the same person (me). For example, I might mirror a website roughly once a month, but with some variation; I would be displeased if despite my efforts to change headers and coming out of a different Tor exit node, it was clear to the other side that it was the same person. This one is less important than general traceability.

Chances are, anyone who looks at the logs will be able to tell it is the same person. The chances that anyone else is using Tor and changing headers (which is not natural behavior) and is doing this roughly once a month and having the fingerprint of a spider is extremely low. While this does not allow the target to know who you are, they may still be able to tell that the activity is coming from the same person. Quite honestly, using regular old wget with no changes (or perhaps the bare necessary ones required to avoid triggering flood detection and such) may be better. People and bots use wget all the time, even with Tor, which means that randomizing your headers will make it such that you won't even be able to blend in with the (already few) people who are using wget and Tor on that site.

don't make myself vulnerable to exploits that a malicious actor without a high level of technical skill could pull off.

There have been multiple instances of remote exploits against wget in the past. This has ranged from fairly sophisticated, like buffer overflows, to much simpler, like providing a 301 redirect to an FTP link that overwrites a local file. You can either run as an unprivileged, isolated user to mitigate this, or use mandatory access controls like AppArmor to confine it to accessing only certain directories.
Your precautions
Some comments on a few of your precautions:

provide randomly selected HTTP headers for each job

HTTP headers are interpreted regardless of their order or their case. Because of this, each utility using the protocol may use a different order of headers or different cases, not just different headers. For example, curl gives the user agent header before the host header, whereas wget does it the other way around. Even when using identical header settings, they can still be distinguished.
For wget:
GET / HTTP/1.1
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.com

For curl:
GET / HTTP/1.1
Host: example.com
User-Agent: curl/7.57.0
Accept: */*

For Firefox:
GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

So what happens if you set wget to use a Firefox user agent? Some IDSes can be configured specifically to detect discrepancies between the reported user agent and the behavior of any given connection. A discrepancy may allow the IDS to know what software is actually being used, or it might just alert it to the fact that the client is intentionally lying about who they are, resulting in the IDS loudly alerting the sysadmin. Take the following wget command, downloading a single page from a website while spoofing the user agent:
wget -U "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0" "http://example.com/secretpage.html"

You would think that that would be indistinguishable from a Firefox user connecting directly to example.com/secretpage.html, right? An IDS would be able to quickly notice that it is really wget and not Firefox, because it would see the following being sent from the client:
GET /secretpage.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: */*
Accept-Encoding: identity
Host: example.com

Now compare this with the earlier example of Firefox headers. This is clearly not genuine Firefox, despite the user agent claiming it is. This is far more likely to raise an IDS alert than simply retaining the original wget user agent (after all, command line tools being used to retrieve webpages usually isn't a big deal to sysadmins).
Additionally, the patterns in which an application accesses resources can be used to determine the identity of the application. Wget has very unique behavior when used as a web spider in the order and speed it accesses resources, as well as which resources it ignores. Curl does not support being a spider so has no behavior. Firefox has some very complex behaviors involving the order in which resources are loaded and whether or not a given resource is pinged or preloaded. As you can see, it will generally always be possible to know that you are using wget if any in-depth analysis is done, and because most wget users are not changing their headers, this makes you unique.

random wait between 0 and 600 seconds

This should only be done if necessary to bypass automatic detection or to avoid flooding the website. While it is random, an administrator looking at the logs will still see that each connection is is waiting between 0 and 600 seconds. This itself is unique. It should not be done to try to act less "spider-like".
Making an automated spider behave as a genuine internet user is exceptionally hard. Many research papers have been written about it, and many research papers have been written showing how to detect it. Given that spammers are heavily invested in their bots behaving like humans, and anti-spam solutions are heavily invested in distinguishing such bots from humans, any solutions that you come up with like using random delays will not be able to get even close to the constant arms-race between spammers and anti-spam solutions. This is like trying to pitch to a major league batter. Any "clever" trick you can think up for throwing the ball will be thoroughly ineffective given the ever-escalating techniques used by major league pitchers and batters. Don't try to make your spider act like a human. You won't win that game. The only winning move is not to play.

all links converted to local references

This only matters if you are going to be browsing the site offline. I would not rely on that if you suspect that the website is malicious, because there could be many ways to embed a link to a website which is not detected and converted by wget, but which is detected and accessed in a standard browser. If you fear the offline mirror attempting to phone home, you should only connect to it from a user which does not have direct access to the content. It appears you are already doing this according to #8.
Threat modeling
Though you did add more details, you should still think about your threat model a bit more. What exactly is it you are trying to achieve by preventing them from realizing each month's scraping activity is related or that it is not natural traffic? I can think of only a few reasons this might be desirable:

You need the website contents for reconnaissance for later exploitation.
You don't want the website to notice and block Tor traffic or introduce captchas or delays.
You don't want the website to serve you with custom (malicious or dummy) content.
You are scraping an accidentally-exposed private area of the website, and bringing any attention to the existence of your traffic would result in the unintended access being closed.
The knowledge that someone is scraping it is enough for the administrator to realize who is likely behind it (e.g. if you are scraping a friend's personal site or a forum which you are active on).

Depending on which (if any) of these apply to your situation, you do not need to expend so much effort in avoiding attribution. Most website access logs are not manually analyzed in detail unless necessary for incident-response. Most even log with low enough resolution that things like specific headers are not saved. You can avoid most forms of throttling and blockage simply by using a private proxy (with Tor, if you need anonymity) and by setting all your headers to that of a popular web spider which uses wget. Throttle and ratelimit your own connections to avoid harming the server and forcing them to take defensive action. Remember Aaron Swartz, the man who was arrested and later committed suicide after being caught downloading a large amount of scientific journals at MIT? He used wget, and was only caught because he was using so much traffic and even evaded blocking attempts that JSTOR ended up banning the entire MIT address range and complained to them about the abuses. If he had used ratelimiting, he would have never been caught, would never have died, and Sci-Hub would be a whole lot bigger.
If the website is not operated by someone with at least a moderate level of offensive security knowledge and motivation to "hack back", exploitation of wget should not be your concern. While it is certainly possible, at sometimes more easily than other times, it is not going to be a likely response from a website administrator. I personally have never seen it happen in the wild, at least. This will be a bigger risk if you are, for example, accessing an accidentally exposed backend of a sophisticated security contractor. If you're trying to download Raytheon SI's internal wiki and all you are doing is using plain wget with torsocks, you are doing it wrong and should stop.
Without at least a little more information on exactly what you are trying to achieve, it will be hard to give you a single, satisfactory answer. The most likely complete solution? Use a VPS. Purchase the VPS anonymously (if that is necessary for your threat model), and connect to the VPS using Tor. Configure wget with some basic throttling and ratelimiting to avoid being blocked. This will not only raise no red flags due to Tor usage, but it will also isolate wget in the case that it is compromised.


What are recommendations for unblocking outbound SMTP traffic in an organization?

You unblock only the ports intended for clients to send mail to their own mailserver. This would be 465 and 587.
Servers on this ports should always require authentication from clients, so they can't be used by spam bots easily.
Port 25 is intended to be used only to send mail from server to server. Don't allow connections there, with the exception of known mail servers in your organization, obviously.

If you have a common ISP that requires mails to be submitted on port 25, I would only ever unlock it if this is a separate server from their incoming mailserver and requires authentication.


Why did PHP 5.6 change how it handles SSL certificates?

With PHP 5.6 the default for using TLS was finally changed to verify certificates by default and verify them properly (i.e. not only certificate chain but also hostname). About the same time similar changes where done in Python (version 2.7.9).

These changes were done because not properly checking a certificate makes the connection vulnerable to man in the middle attacks. But, relying on developers to add the functionality to properly check certificates does not work because it seems to work without too so why add additional work to make it more secure. This means that having the secure behavior enabled by default is the only acceptable option. Additionally, both Python and PHP did not even have a way to properly check certificates before, i.e. all they could in an easy way is to to check certificate chain but not the hostname.

It is probably no coincidence that these changes were made while many sites switched to HTTPS in aftermath of the Snowden affair and because the revelations of this affair showed that sniffing and hijacking of improperly protected connections was not only a theoretical thing but that government agencies actually made use of it.


Should I NOT choose a password of max allowable character length?

Assuming that the passwords must consist of printable ASCII characters (of which there are 95), the number of possible 32-character passwords is 9532 ≈ 2 × 1063.

Meanwhile, the number of 31-character passwords is 9531 ≈ 2 × 1061, i.e. about two orders of magnitude less.  (In fact, they differ precisely by a factor of 95.)  The number of 30-character passwords is even less, 9530 ≈ 2 × 1059, and so on.  In fact, the total number of possible passwords of length less than 32 equals:

    9531 + 9530 + 9529 + ··· + 952 + 951 + 950

 = 9532 × (1/95 + 1/952 + 1/953 + ··· + 1/9531 + 1/9532)

 < 9532 × (1/95 + 1/952 + 1/953 + ··· + 1/9531 + 1/9532 + 1/9533 + 1/9534 + ··· )

 = 9532 × 1 / (95 − 1)

 = 9532 / 94

Thus, the number of possible printable ASCII passwords of exactly 32 characters is 94 times greater than the total number of such passwords of less than 32 characters.  Thus, if an attacker is able to crack a 32-character password by brute force, it will take them, on average, one 94-th of the time to crack any shorter password.

Of course, this assumes that your passwords are randomly chosen out of the space of all eligible passwords.  Few real-world passwords are such, but as a rough approximation, we can still assume that the amount of work needed to guess a password by brute force grows exponentially with the length of the password — the base of the exponent will just be something smaller than 95.

Also, there's nothing special about the number 32 in the calculation above.  Replacing it with any other maximum length will yield exactly the same result: it's always a good idea to make your passwords as long as possible, at least up to the point where the password is long enough to make brute force cracking essentially impossible.

Where is that point?  Well, the general consensus among cryptographers is that 264 ≈ 2 × 1019 brute force guesses can be done with enough effort, while 2128 ≈ 3 × 1038 guesses is probably beyond the capabilities of any currently existing or foreseeable attacker (yes, even the NSA), and 2256 ≈ 1 × 1077 guesses is definitely beyond the capabilities of mankind.  The effort required to crack a random 32-character ASCII password by brute force, i.e. 9532 ≈ 2 × 1063 guesses, is between the latter two, but definitely closer (on a logarithmic scale) to 2256 than to 2128, both of which are currently regarded as unbreakable.  Thus, we can safely say that, if your password is a random ASCII string, 32 (or even 31 or 30) characters is quite plenty enough.


Possible to read strength of encryption?

Is it possible for someone in the middle of an encrypted channel to tell the size/strength of encryption used?

In a well-designed algorithm, encrypted data should be indistinguishable from random noise. Some formats normally have header fields. e.g., PGP in asymmetric mode will tell you what the intended asymmetric key id is and the intended symmetric algorithm will be encrypted with that key. I'm unsure what header is output in symmetric mode. Zip files will specify algorithm and bit size clearly in the header. 0x66(0E|0F|10) map to AES(128|192|256). The spec does allow setting the field to 0xFFFF for "unknown algorithm".

Thus, the answer is entirely implementation dependent. Without specifying a header, it should be impossible to determine algorithm and bit length without decrypting the contents through brute force.


Safety difference between running on localhost versus the private internal ip address?

I do not think there is any security increase, rather there would be a security decrease.  The localhost or 127.0.0.1 is only accessible from the host computer, or the computer running the web server.  A website listening to only 127.0.0.1 under normal conditions, would never be accessible to any other computer on the private network.
Using a private IP address, you open the webserver to all communications on the private network and communications that are forwarded by the load balancer, to the web server from the internet.


Suspicious Network Activity - is my system compromised?

I had this same issue about 2-3 weeks ago, with the same site coming up after running several scans with Roguekiller.

Prior to that the browsers would lock up or work very intermittently, (Firefox, Chrome, Edge, IE , Opera, ect.)
Using a web browser in a game, running a VM or Tor worked, but even Tor would lock up after an hour.

This was on Win 10 64bit, with malwarebytes (full), Sophos home and malwarebytes anti-exploit running. No Java or flash installed, Ublock origins and Noscript installed for Firefox, built in flash turned off in Edge.

Uninstalling the browsers and resetting IE, then reinstalling other browsers would work for maybe a day before the issue re occurred. (Even removing IE and using other browsers on fresh installs, same issue!)

Malwarebytes blocked connection attempts to the pc 5+ times a day while this was going on, after roguekiller picked up the hooks and reg keys, no more issues ;)

Nothing was picked up on scans (MB, Sophos, or roguekiller) until the most recent update for roguekiller however! Drove me crazy, I ended up making live cd's to boot from to surf with.
Browsers did work in safe mode btw.

I did assume that realty company had been breached or was just a fake when I saw the address as well.


Some headers are a bigger problem than others. e.g., if you aren't planning to serve any IE browsers, I wouldn't worry much about X-Content-Type-Options: no-sniff.

The effectiveness of some are debatable. e.g., X-XSS-Protection (did I just provoke a comment war? :) ).

Some headers are definitely useful nearly for every application. e.g, HTTPOnly;secure

Other headers are important based on the sensitivity of your application - e.g., strict-transport-security.

In general though, most of these are low-barrier security protections (CSP & HSTS/HPKP need prep, yes) and there is no good reason not to use them.


Why 2FA is not considered flawless when used to secure an account?

Well, I hate to break this to you, but Google Authenticator plus password isn't really two-factor authentication. Proper 2FA is two separate items out of traditionally the triad "something you have" (physical item, which may itself hold a secret), "something you know" (secret), and "something you are" (often biometrics).

Password plus Google Authenticator is probably better summed up as password and soft token, as Troy Hunt did in a recent blog post. Basically, the app stores a secret, and uses that secret to generate temporary passwords.

If someone is able to break into your phone general-purpose pocket computer with a variety of radio interfaces running arbitrary, potentially hostile, software, they could presumably find some way to extract those secrets. Once extracted, they could likely be transplanted onto a different phone, which would now generate the same temporary passwords.

This doesn't mean that a "soft" 2FA is meaningless. It does raise the bar considerably for an attacker. But it's still a variation on "something you know"; only that the knowing part is done by your phone, rather than by your brain (or, hopefully, password manager).

To make a claim that something is "flawless" means that there must be, at a minimum, no conceivable way by which it could be exploited by an attacker. This seems a rather high bar to meet for a general-purpose computer running arbitrary software storing a high-value secret.

Better to just stick to saying that it makes an attacker's job more difficult.


It depends on the law in your country and the law in the country the registration company is in. In Europe domain names are subject to the trademark law. So a domain name violating a trademark is a valid reason to go to court.


Unknown bot using Firefox 40.1 user-agent

This user agent string is used by a brute force that tries to login as an administrator to a Wordpress site. For me the bot tried about 3000 times within about 18 hours with no success.


Creating my own tokens to secure communication with my API

Is it possible to re-use an authorization mechanism, such as OAuth2?

Your client get a valid access token upon challenge (userID, secret) which is cryptographically signed.  Your server app can verify this token, and potentially take out any claims from it; so you don't need to look it up in a DB.  Even if you want to look something up, you'd need to look at in-memory key-value stores/caching mechanisms such as Redis.

The on-boarding (signing up / logging in) would be performed by an IdP, an identity provider.  See it as the system doing the actualy verification.  It will reply a unique token to the client; encoded and signed.  As long as your API makes sure that this is a valid token (signed by the right guy), then you should be good.

  Is it okay to send plain-text salt+password to api since it is
  SSL-protected, then hash it on server-side?

If you salt your password client side, then it just substitutes the password.  Unless someone does a MiTM (intercepting proxy, ...), and you don't log the request body, ... SSL would prevent you from eavesdroppers.  Whether you use the password, or the hash of the password; an attacker who captures it, would just send the hash as well.

  ...Wouldn't someone just be able to grab their
  access token from the preference-file and make calls to my API from
  their own app

Yes, everything that's on the client cannot be trusted.  You can try to obfuscate it a bit, but essentially, you can't be sure that it was your application sending it; and not another program (from someone who took the time and effort to reverse engineer it)


Is the random salt saved somewhere to be used for each encryption?

Yes

  Seems less secure to me if the salt is saved right alongside the hashed password, rather than using some kind of computed salt an attacker would not inherently know if they got a hold of your data.

It's not, because the only thing a salt does and was invented to do is, as you said:

  to fight against the likelyhood of being cracked by a rainbow table

and nothing more. It adds complexity to a single password - and for every password in a database, it is unique. To verify the password, you need to store it alongside it. This doesn't compromise the security of that single password in the least bit - the hash algorithm is still as secure as without a salt.

But, looking at the whole database, every password is better protected against rainbow attacks, because the attacker must calculate very single hash with the respective salt separately and cannot do bulk operations on them.


Secure use of psexec or better alternative to it

Is this a windows enviroment?

If powershell is an option maybe try something along these lines?

Powershell Invoke-Command CMDLET


Convert customer tracking system from web access to REST

Well, after several months of just repeating questions to get repeated answers we're moving to different provider. Suddenly REST, JSON and one IP only is secure enough for the other guy be simply ecstatic.

Thanks to all contributing in comments above - it's always good to know that there are people agreeing with you. And you still helped with asking same question in different, better way.


Detecting code source variants of the same function

It is an undecidable problem. It is as difficult as the halting problem.

You can see the question and answers in https://stackoverflow.com/questions/23487045/can-an-algorithm-analyze-the-behaviour-of-a-function-and-say-if-another-function


OpenBSD does not require a "live" cd and if you want to err on the paranoid side you should consider creating your own "live" medium by following their own FAQs:

  It is very easy to create a bootable USB flash (or other!) drive that can be used as a "live" OpenBSD system without installing OpenBSD on the local hard disk of a machine. Obviously, the target machine must be bootable from a USB device, but the initial load can actually be done from any machine with a USB interface.

Benefits: if you have an OpenBSD installed you can verify the authenticity of the bsd.rd file by checking it against the public keys embedded in each distribution (see this paper but also google for openbsd signify):

  After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation.

If you don't have an OpenBSD installed and you only want to check hardware compatibility, download (and verify!) the bsd.rd file, dd it on a portable medium, then boot it and give it a go.


Storing a whitelist of access tokens in a database is a great way to perform access token revocation; if it's not in the DB, don't accept the token. However, this undermines one of the main advantages of JWTs: being able to verify tokens without having to access to a centralised DB. Usually, the short lifespan of access tokens is considered a good enough safeguard to make revocation of access tokens unnecessary. Refresh tokens can be revoked though (by disallowing a particular user from generating more access tokens).

Storing a unique key pair per user is not a great idea. They use much more storage than tokens and therefore take longer to read and write, and are time-consuming and CPU-intensive to generate. It also achieves little in the way of security.

Frequent key rotation is a better idea. Multiple signing keys can be in use simultaneously, with the key identified by either the 'kid' or 'x5t' claim in the JWT header.