Creating secure virtual machine that nobody can see its content including the host machine?

Protecting memory from the host is going to be the tricky part.

Testing

My Setup

To demonstrate this, I have this system lying around:

Host: Ubuntu 18.04.4 LTS
Virtualization stack: VirtualBox 5.2.34
Guest: Kali linux 2018.3

Experiment

In Kali, I opened a text editor and typed the text "SecretForcn271828n", but I did not save it to disk, it's just in memory. The test is whether I can read that from the host.

Steps

From the host, the entire VM appears as a single process:

➜  ~ ps -aux | grep Kali1
mike      6014 12.2 23.6 4524784 1901772 ?     Sl   19:48   3:26 /usr/lib/virtualbox/VirtualBox --comment Kali1 --startvm 7b229c8a-ba68-48ad-bd80-0ab5ed9b6b86 --no-startvm-errormsgbox

So I'll take a core dump of that process:

➜  ~ sudo gcore 6014
...
Saved corefile core.6014
➜  ~ ll -h core.6014
-rw-r--r-- 1 root root 2.3G Mar  3 20:02 core.6014

That core file contains a complete dump of the memory of the kali OS, plus whatever memory the VirtualBox stack itself is using, as seen by the root user on the host.

Now let's use the strings utility to see what's in memory!

➜  ~ strings core.6014 | grep -i secret
ccSecretForch271828n
SecretForch271828n
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
-- INSERT --                                                  1,19  All
SecretForch271828n

That certainly looks to me like the host can see the raw memory of the gvim application that is running inside the kali VM.

(this was actually all on one grep line, but I formatted it pretty)

Summary

Trying to protect a guest VM from the host is a losing game. Anything that is in raw memory within the guest will be visible to the host. The CPU instructions executed by the guest are likely similarly visible, but it's beyond my skill to demo that.

It might be possible to build a guest OS, or maybe a hypervisor or virtualization stack, that adds some memory obfuscation (such as encryption of live memory). This would come at a pretty steep performance hit, and at best it would be obfuscation because, with enough effort, and attacker who controlled the host could find the encryption key in memory of the guest OS or virtualization stack.


Is HTTPS based on a private key on the user side?

Generally, a symmetric key is negotiated on the fly, and securely exchanged between the browser and the server.  One protocol that enables people to do this (Diffie-Hellman key exchange) is explained in this excellent youtube video: http://www.youtube.com/watch?v=3QnD2c4Xovk.

The random data for that is derived using any number of methods; it's certainly not static, and it generally won't have much to do with the current time.  The classic example is to use the number of microseconds from the time, which is something that knowing the time of day to the second won't help.  Other sources include the timing of certain events (keypresses and disk accesses, as common in linux), the number of photons reflected by a semitransparent mirror at some moment (quantum-derived entropy like many SSL accelerators use), or the action of a metastable oscillator (the intel DRBG), and several other things.  This random data is collected each time it is required, though in practice it can sometimes be stored in a pool for later use (which can be a vulnerability also, but that's another topic).

Since the key is quite random, you need to do a lot of bruteforce to get it.  If you maximized the amount of entropy you could  use for your key, and the cipher used a 256-bit key (AES-256, etc.), you would have to try a lot of times (2^256 * 0.50 attempts would give you a 50% chance of recovering the key).  In practice, a lot of people use less entropy than this and construct the rest of the key deterministically, which means that if they used only 64 bits of entropy that formula would change to 2^64 * 0.50, as long as you knew exactly how the key was being generated.  For DH key exchange like I mentioned above, the math is actually a little more complex because you have to account for the fact that you're choosing two random numbers and not one.

This is a lot of keys, and the odds of most attackers breaking one by bruteforce before you've stopped using it are very minimal.


Setting up communication between internal database and hosted web server by third party

Would this be considered a reasonably safe configuration?: No.

The hint here is Company doesn't want to put the data on the third party server. I assume there are good reasons for that. The problem is that if you directly let the web server on the remote host directly access your local database, it just means that the external server gets a direct access to you internal database server.

Database servers are honestly secured, but they are not meant to be direcly under the threat of direct attacks. So when you ask about best practices, this is not one. Definitely.

The correct way would be to build a minimal REST web application in a DMZ inside your internal network. It should be accessible from the external server that will send requests to it, and this relay will has direct access to the internal database. You have to apply standard rules (SSL) to secure the communication between the remote host and the relay, install the minimum on the relay (the more software, the higher risk), and allow as few users as possible to access it.

That way even if an attacker could take control of the remote host, he will still have to pass the local relay before directly being able to attack the database. Ok the requests could already be harmful, but IMHO far less that a direct access.


Why is one of three browsers (Chromium) reporting an invalid HTTPS certificate?

I suspect this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=664177

It's harmless - this is not an evidence that someone is attacking your connection.

Next update of Chromium should fix this.

They'll shake out all the bugs in CT before the October 2017 date of CT becoming mandatory for all newly issued certificates.


How exactly does Windows Defender in Windows 10 determine when to upload your local files to Microsoft?

This is actually a simple and clear policy by Microsoft (but it may have deeper issues):

Even if you choose to accept the Automatic Sample Submission feature remaining enabled, if the file Microsoft is requesting is a data file of any sort, then there should be a prompt to confirm. The only files that Microsoft will send without confirmation are executable files, which for most consumer users are not personally created items.

Now there's another dirty trick to all this:

A document is not an executable, but it may contain executable code. Therefore, MS may consider it an executable and auto-submit it, but they officially state in the case of a Word document or Excel spreadsheet that seems to contain a potentially dangerous macros—you’ll be prompted before it’s sent to Microsoft. The problem here: how they interpret a file with personal information. Some less known programs may use various not widely known extensions which may not be treated as a document holding personal information.

This behavior also may vary depending on updates/versions so the only way to be 100% certain of how it acts is by practically testing.

Also, one should be careful with the Cloud-based protection feature. Specially crafted files may end-up actually doing damage to non-malicious files. Even if such a thing did not yet happen on large scale, one must not exclude for such a possibility.

Harassing is indeed over-exaggerated in Windows 10: it happens in many cases when it comes to 'features' or updates. Example: after it kept stressing me about a reboot required for updating, I bypasses the system and scheduled the reboot for 2099. After that, a desktop notification stared to appear to remind me to reboot before schedule.
So this system of spam-like notifications practically acts more annoying than an actual fake anti-virus.


The phone provider isn't specifically collecting location information, usually. They're collecting usage data about their phone masts, so they can upgrade bandwidth to heavily used ones, plan maintenance out of peak usage hours, and other technical reasons. This includes details about devices which are connecting to a given mast at a given time, since it's useful to determine things like handover.

Google will try to collect more accurate positioning data. They can use GPS to pinpoint phones to within a few metres or so reliably. This can be sent to Google to enable various features like preparing offline maps of commonly visited locations, being able to notify you about travel delays on commonly used routes, and being able to tell you about local services when you search on terms like "restaurant" or "police station". In order to get that data to Google, there needs to be some kind of internet connection active - WiFi or mobile data.

If a criminal is using a phone, and they are sensible, they'll make sure that they've disabled the precise positioning data upload (they can still use Google Maps, if they've got an offline map - that just requires the phone itself to know where it is, and be able to find that on a pre-downloaded map file). That means that the precise positioning data isn't available. However, the cell level data is still around - that doesn't require any data connection, just a standard mobile signal. If the criminal wants to use a mobile during the crime, they can't cover that up. And it doesn't even have to be active use - mobile phones try to connect to nearby masts on a regular basis, so they can receive calls. They'll sometimes try and see if another mast has a better signal, too.

There isn't any particular reason why a phone provider couldn't collect more precise location data - they could pre-load phones they supply with monitoring software, for example. However, it would be a bit of a PR nightmare to deal with. There also isn't any particular reason why criminal investigations can't ask Google for the information, but it tends to be harder to tie a specific device to a location - the data tends to be collected on an account level - and may well involve international requests to get the data, whilst phone provider data will usually be available with a local warrant from a judge in the source country.


A JWT token consists of a base64 encoded string containing header, claims and signature.

The claims section contains a JSON encoded expiration field, exp:

  Expiration time. It contains the UTC Unix time after which you should
  no longer accept this token. It should be after the issued-at time.

The username can also be stored in the claims object.

There are two options regarding "signing" of the JWT:

  JWTs can be signed using a secret (with the HMAC algorithm) or a
  public/private key pair using RSA.

With the secret, there is a private key, however this is used to authenticate the message using HMAC SHA256. There is no encryption, just authentication so a client could work out what was stored in the token, but not change it. HMAC is a way of calculating hashes without them being vulnerable to length extension attack. There is no public key in this method.

With RSA, the private key is used to sign the key, which can be verified using the public key when received by a client. Therefore only the component generating keys needs to know the private key.

See Understanding JWT for more information.


How are leaked government credentials possible and what's the point?

What's the point of stealing hashed passwords?
Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password.
For example, assume that under some hash function we get the following hash table:
"cat" --> AA
"dog" --> AB
"elephant" --> AC
...

If I steal a password database and see that your hashed password is AB then I know that the plaintext password is "dog". (technically, more than one string will hash to "AB", but since the server is comparing hashes, not raw passwords, any of them will let me in. So in effect your account has multiple passwords; any string which hashes to "AB" is a valid password for your account.).
Attackers can crack hashed passwords by pre-computing hashes for large numbers of potential passwords (usually obtained by combining dictionary words, or from lists of previously cracked passwords), and then using this as a lookup table to convert hashes back into plaintext passwords.
This kind of attack is generically referred to as a Rainbow Table Attack, with introductory explanations here and here.
One issue with rainbow tables is that to cover any reasonable number of candidate passwords, the size of this lookup table grows to terabytes and requires multiple hard drives just to store it. As you can imagine, attackers have developed fancy tricks for optimizing the reverse-hashing process, so while the general idea of rainbow tables is simple, actual optimized implementations get very complicated very quickly.

It's worth mentioning a few of the common counter-measures that db admins and developers use against rainbow table attacks.

salting is the trick of appending a random string (the 'salt') to the raw password before hashing it. Each user has a unique salt which means that, in effect, each user uses their own unique hash function, so an attacker can't re-use rainbow tables and has to pre-compute a brand new table for each user.

Take the password and run it through a large number of salt-and-hash iterations of a strong cryptographic hash function before storing it in the db (for example, 100,000 iterations of SHA-2), which makes it much more expensive to pre-compute the rainbow tables. It also makes it slower for users to log in.

Use a hash function which takes in a private key (these hash functions are called HMACs). The idea is to use a private-key known only to the server in computing the hashes so that it's impossible to compute a rainbow table without knowing the key. The problem with this is that when an attacker has enough access to steal a whole database, they can usually steal the private key as well.

In your question you also mention storing encrypted passwords. This is similar to 3. in that, unless you have a good way to protect the encryption key (for example, dedicated hardware like an HSM), then the attacker will steal the key along with the database.


What can be done to harden typical consumer networks?

Anyone attempting to set up a "secure" home network with "smart" devices is going to have to make some compromises either about security or about ease of use.

I would say the first thing to do is to segment your network into at least 2, possibly 3 or more.

One for data access from reasonably protected End User Compute (EUC) devices (including desktops, laptops, tablets and mobiles). This network should not allow any inbound connectivity (standard firewall configuration). You might also consider segmenting your Wi-Fi network though this can be a pain to use since devices on wired and wireless connections may not be able to talk to each other without additional configuration. Certainly consider a guest Wi-Fi SSID.

This segment will also be used for media devices - these need access to the Internet but will be less secure as they get updates less often (maybe never) and vendors have nasty habits with your privacy. You may be able to segment these devices too if you don't need much access from EUC devices and that is certainly preferable.

The second main segment would be for IoT devices - typically, you should never allow these direct access to the Internet. Of course, if you have purchased devices that only work via an Internet facing service, you are rather stuffed there, those devices would have to go on your main segment but you should at least consider setting up firewall rules that only allow specific devices to talk to specific service endpoints. All other IoT devices may be allowed to talk to each other but not the Internet - well not directly anyway. Consider a home hub of some sort where you can control traffic securely - that's a separate question really. If you need to access IoT devices from EUC devices, configure specific routing to allow that.

In my own setup, IoT devices have access to a Raspberry Pi running Node-RED which is the hub. That Pi does have outbound access to the Internet but there is no inbound access. For offsite alerting, I use a Telegram "bot" which provides end-to-end security without the need for firewall rules. The Node-RED derived bot reaches out to the Telegram servers which allows secure, 2-way communications.

I never buy IoT devices that require external services to work. Not only does this potentially compromise security, it also means useless devices if/when the vendor loses interest or goes out of business. I may make an exception at some point for a "smart speaker" such as Alexa or Google Home. But that would not be controlling anything important in the house.

Wi-Fi camera's are another source of security issues. Again, I'd advise against connecting them direct to the Internet. Treat them as IoT devices and use a secure hub to act as a proxy if you really need external access to the video. It may also be possible to again use a Telegram bot to send video securely.


GnuPG pre-2.1 (ie. GnuPG 1 and GnuPG 2) cannot merge private keys. There are different ways to scope with that:

Install GnuPG 2.1, which finally resolved this limitation.
Import the private primary key to a new keyring (--homedir will come in handy for doing so), for revocation you only need the public subkey, no private ones.
Use gpgsplit to break up the exported secret keys into the individual packets, and concatenate them again in the right order. This works very well, but requires deeper knowledge of RFC 4880 (OpenPGP).

I'd propose to go with GnuPG 2.1, and if necessary export the private key(s) again and switch back to GnuPG 1 or 2 if you prefer.


Hash value changes after first opening a file

Unless the content of the file changes in any way, it is not possible. Hashing algorthims rely on the content of the file to determine the hash of the file.

Unless the file has changed its own content upon execution, or you have written to the file in some way (even metadata within the file itself), then the hash will not change. One flipped bit in a file will cause an entirely new hash in a secure hashing algorithm.

In short - if you see a different hash, the file's contents have changed, even if it is by one bit.


SMTP Service STARTTLS Plaintext Command Injection

Based on the links you've provided, this appears to be CVE-2011-0411.  Given a CVE, you can browse at suse.com to see which packages will fix it.  In this case, postfix >= 2.5.6-5.6.1 (patchname: slessp1-postfix) will correct the issue for SLES 11.


Can it be a vulnerability to show stars in password entry fields?

No, there is no good reason to hide password length and if this is done then it's usually for other reasons like it being easier to implement.

It is bad user experience and a shoulder surfer can pretty easily count keystrokes.


1) Yes, both are available.  Databases can support field level, table level or full database security.  They can also support externally controlled keys (provided by the client on connection to the DB) or DB managed keys (that are stored in the database and protected by the client's login credentials.)

2) Database encryption that doesn't apply to a live database would just be file encryption, though database encryption does still protect a live database that has been archived or backed up.

3) Not if the encryption is handled by the DB itself.  The login account can unlock encryption keys stored in the DB and a good DBMS can handle the encryption/decryption transparently.  If the encryption keys are handled by the client, then the connections would have to be updated to provide the key when accessing the data.

4) Any good DBMS should include built-in support for database encryption.  You should not need a third party tool.  A third party tool is not going to do as good of a job since the DBMS needs to know how to access the encrypted records to do a good job.

5) It is not a bad alternative, though it is not nearly as secure.  Encrypting a database protects not only against data at rest, but also against data being compromised while the server is running.  If the server itself is compromised while running, Bitlocker will do nothing to protect the database.  Database encryption on the other hand will protect the data even if both the server and the DBMS are compromised (though a severe DBMS compromise might allow leakage when records are accessed by a legitimate user).


I think probably the XSS is mitigated using Response Headers like

X-XSS-Protection
Content-Security-Policy
X-Content-Type-Options

You can read more about these Headers here . If these headers are implemented properly, the injected script will not be executed as Javascript by browser and prevents XSS.


Are there any known vulnerabilities in libre office password protection for *.odt files?

According to the OpenDocument Specification, these files use a strong encryption with no known flaws.

...This digest is used to produce a derived key by undergoing key stretching with PBKDF2
...ODF 1.0 and 1.1 use Blowfish in 8-bit cipher feedback mode, while ODF 1.2 considers it a legacy algorithm and allows Triple DES and AES

However, like almost every encryption algorithms, odt files are vulnerable to bruteforce but, according to this post it's not very efficient and if your password is strong enough you should be fine.


Proof that data has been encrypted/destroyed by the user

Let's say you sent me a file. After a month, I decide to delete it. How on Earth do you expect to notice about an action done in my local machine?

And if magically you could do so, what's preventing me to send you a fake "confirmation" message that the data has been removed?

So to answer your question, no, there is no reliable proof that data has been encrypted/destroyed by the user.


Should business logic attack be one of the testing methods during pentesting or vulnerability assessment project?

Business logic attack is more like a "business logic testing" which is normally done before launching the application by the developer team (more preciously, the Quality Assurance team) of the application.

Before performing in a production level, an application must have gone through business logic testing. Though, there is still rooms for putting "Business logic attack" into vulnerability assessment checklist specially when the application is running for financial organization.


What is the best way for OWASP Zap to handle Unique Fields and API Sequences?

For situation one, create your own variant or HttpSender script.

https://github.com/zaproxy/community-scripts/tree/master/variant
https://github.com/zaproxy/community-scripts/tree/master/httpsender

For situation two, use the Sequence addon:
https://www.zaproxy.org/docs/desktop/addons/sequence-scanner/


X509 "Serial Number of certificate" vs serial number attribute in Issuer and Subject?

The serial number of the certificate is not related to the serial numbers of the issuer or the subject - if these have serial numbers at all.


https: Is my company connection intercepted?

Even though we are using a proxy, it is sufficient to check the certificate hierarchy and when it's the same inside the companys network and in my home network, I can conclude I'm not being sniffed the inputs I do

You can conclude that you are not sniffed for this specific site and this specific time only.

  The procedure of the proxy-server to "insert" a faked https-certificate, in case there would be such a system in-place, would probably be made system-wide. That means, as I only compared the certificate-hierarchies on a few domains now, it should mean such a procedure will highly likely not be in-place at all, also not for any other domain?

It is possible to intercept only selected sites or only at specific times or only specific clients (based on ClientHello fingerprint) or to explicitly not intercept some sites. Thus it is not possible to conclude from one site not being intercept that other sites will not get intercepted too or even that the same site gets not intercepted at another time or with another client. You might check if you find some unusual root certificates in your certificate store but these are not that obvious to detect.

  That means the only way to track my inputs, would be to use some sort of keyloggers? (Which is probably not possible / allowed by law anyhow (living in germany)).

There are several ways to monitor users apart from keyloggers and HTTPS interception. For example browser plugins could be used or simply the whole system could be mirrored similar to  remote desktop software.

  From what I gathered from the other posts here on stackexchange, they can obviously save from the logs which URLs/hostnames I have visited. They question is: Do they see the full URLs or only the hostname / the target server? Because it could potentially do a big difference whether I visited some reddit page about how to setup some software or some reddit page about po*rn :D Obviously I won't visit these, just from a technical POV I want to know what's possible here.

Only the domain is known and not the full URL. See Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable?.


There are no indications of a compromise in the logs. They only show at worst port scanning. This is the act of looking for open ports, the next stage if open ports were found would be to check the version of software running and then to try to exploit potential vulnerabilities to gain access. This would show up in the logs as well (as long as the IDS has not been incorrectly tuned).

However, it would be worth looking at the web server logs to see if the source address of this activity corresponds to a valid IP using the web server. Sometimes when clients try to connect to a service they make a connection on the remote port (in this case 443) and the server attempts to open up a high port for the return traffic. If this is blocked the connection may try to establish a different high port and so on. This can have the effect of looking like a port scan.


Is receiving IPv4 connections on AF_INET6 sockets insecure?

Most of these security issues arise when a host accepts IPv4-mapped IPv6 traffic over the network, rather than accepting IPv4 traffic and presenting it to an application on an IPv6 socket with a mapped address. An application may have no good way to tell the difference and detect a potential attack in progress. Of course no host should ever be accepting mapped addresses from the network, but since when have operating systems ever behaved perfectly?

RFC 4942 § 2.2 explains the issues in depth:

  Overloaded functionality is always a double-edged sword: it may yield some deployment benefits, but often also incurs the price that comes with ambiguity.

  One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a representation of an IPv4 address as an IPv6 address inside an operating system as defined in [RFC3493].  Since the original specification, the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire.

  Therefore, it becomes difficult to unambiguously discern whether an IPv4 mapped address is really an IPv4 address represented in the IPv6 address format (basic API behavior) or an IPv6 address received from the wire (which may be subject to address forgery, etc.).  (SIIT behavior).  The security issues that arise from the ambiguous behavior when IPv4-mapped addresses are used on the wire include:

  If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (specifically, the IPv4 loopback address, 127.0.0.1).  The same attack might be performed using the node's IPv4 interface address instead.
  If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff:10.1.1.1), he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall.
  If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks.  For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks.

  In addition, special cases like these, while giving deployment benefits in some areas, require a considerable amount of code complexity (e.g., in the implementations of bind() system calls and reverse DNS lookups) that is probably undesirable but can be managed in this case.

  In practice, although the packet translation mechanisms of SIIT are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different from IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses in IPv6 addresses.  Also, SIIT is not recommended for use as a standalone transition mechanism.  Given the issues that have been identified, it seems appropriate that mapped addresses should not be used on the wire.  However, changing application behavior by deprecating the use of mapped addresses in the operating system interface would have significant impact on application porting methods as described in [RFC4038], and it is expected that IPv4-mapped IPv6 addresses will continue to be used within the API to aid application portability.

  Using the basic API behavior has some security implications in that it adds additional complexity to address-based access controls.  The main issue that arises is that an IPv6 (AF_INET6) socket will accept IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. This has to be taken into account by application developers and may allow a malicious IPv4 peer to access a service even if there are no open IPv4 sockets.  This violates the security principle of "least surprise".


It is highly unlikely that your ISP would hack you, since they can easily (and without a trace) watch all your data go by on the wire.

However, since you said there is a strange computer connected to your network, that sounds like an intruder on your network, perhaps trying to perform a MiTM attack.

You should reset your router to factory settings, use a strong (24 character, randomly generated with special characters) password, disable WEP and WPS, use WPA-2, disable remote access to router panel, and force it to be on a wired connection to access admin area.


Are there any laptops which feature hardware security modules to prevent password brute forcing, such as in iPhone's secure enclave

Yes, most laptop CPUs nowadays supports a built in CPU mode for a secure enclave, for example Intel SGX and AMD TrustZone. They effectively implements secure enclave, by preventing code running in the regular mode from inspecting or controlling the code running in the trusted execution mode. In the case of Intel, the secure enclave also runs x86 code, while AMD embeds an ARM TrustZone co-processor that only runs the secure enclave program.


Is it possible to hack a phone just inputting dialer codes?

She could of done 2 things that would make you pay something extra:

Hailed a number that overtaxes and since the first minute is most of the time taxed by default no matter the duration up to 60 seconds she actually did make some amount of currency with the few seconds when it was active
Sent a text message to a special service, again, overtaxing you

By your description, it was a call, not a text. Using "#" parameters she left no trace of the destination. Only your mobile operator could help you identify the destination unless you had a key-logger active.


Real random data are 100% unpredictable. Interfaces like urandom additionally provide uniform distribution on top of this, i.e. you get not only unpredictable random values but all values have the same probability. If you already have such a high quality source of randomness then hashing will not improve it any more, i.e. hash(time()+urandom()) will not be better than urandom() alone.

But the code example you have falls back to the simple random() function if urandom() is not available. This is usually only a fast pseudo random number generator where the values are somehow predictable if you know enough of the previous values. Thus hashing the output together with a salt and the time might be an attempt to make the output less predictable when faced with a pseudo random number generator only. And while it does not really add more randomness to the output, it makes it harder to get back to the original pseudo random value and thus makes it harder to use attacks against the underlying pseudo random number generator. For real random data you don't need such kind of protection because the input data are fully unpredictable already and there is no way to compute the next random value if the previous ones are known.


How to export application metrics out of PCI environment

You'll just have to follow your PCI procedures. You'll have to create a change that allows the statsd server to exist. A manager will have to review/ok the change.

It will cause a few dependent changes and activities:

add a new statsd server to the DMZ (network change, system change, system hardening, configuration standards)
add the statsd service and graphite service to the allowed services on the network
record the new server in your equipment overview
update the network diagrams
Allow selected servers to access the statsd service. Be sure to practice least privilege principle. (firewall change)
Allow the statsd service to (only) access the remote graphite service (firewall change)
If applicable, update procedures to add "allowing access to the statsd service" as a default configuration for new machines. Be sure to practice least privilege principle.
Consider wether this change constitutes a significant enough change to need a penetration test
Kick off an internal vulnerability scan which includes the statsd server
Alter the application to include statsd support (application change, code review)


Your honey pot will be taken over by the attacker; that's the point. So anything that can be done from that machine will be power granted to the attacker. Therefore, you should configure things such that the attacker does not gain any new power that way. This means the following:

All other machines in your network MUST consider the honey pot as hostile (after all, it is the attacker's machine -- or will be at some point).
Beware of IPv6 ! Many operating systems enable some link-level IPv6 networking by default, and that could be used by the attacker. Better place your honey pot in a subnetwork of its own (your VM should be able to do that).
You should endeavour to block outgoing traffic from the honey pot. Otherwise, the attacker may use it as a relay to start attacking other, external systems, and that second attack will seem to be coming from your network. At best, you may be able to prove that you were just an innocent victim, but one could claim that by setting a weak machine which could be use as a relay, you just became an accomplice. You should block outgoing TCP connections, and for UDP packets, only allow DNS request to a specific server (e.g. Google's 8.8.8.8).

If your VM technology is VirtualBox, see the manual. You will probably want to use host-only networking and setup firewall rules on the new loopback interface that VirtualBox will add to the host.

One can guess that I am not a huge fan of the honey pot concept. It is somewhat fun, and a good research tool when studying attackers' behaviour, but it is also risky, both technically and legally.


Look to:

Truststore vs. Keystore - Trust store contains the public parts from others and the keystore contains the personal certificate (and key).
Keychain - the Apple password manager.

[edit]

Now that it has been clarified that the KeyChain in question is the Android API, that would best be described as:
see

  [...] regulates application access to the system key store and allows users to grant application access to the credentials stored there. Additionally, this API enables applications to initiate installation of credentials from X.509 certificates and PKCS#12 key stores.

So it is a way to access the truststores and keystores.


How to prevent users sharing WPA RADIUS keys?

If the devices are not owned by the company you cant avoid key sharing. Restricting to X devices is usually done with MAC checks which can be bypassed.

If the devices are owned by the company, you can use authentication that uses hardware methods (for example a TPM), or software methods


NVD: How to query without false positives when CPE Entries are not filled in for many CVEs?

Since you did not delivered some examples, such as: where did you get information that a CVE does not deliver CPE - either by the basis of some platform or files provided by some specific vendor. I assume you are using the National Vulnerability Database (NVD) Data Feeds, either in XML 2.0 or JSON  format provided by NIST at https://nvd.nist.gov/vuln/data-feeds, because the information collected from NIST's (NVDCVE) files is the same in CVEDetails.com.

You claim that there are over a thousand entries without CPE:

$ ls -lh
total 96136
-rw-r--r--  1 test  test    44M Aug 18 03:25 nvdcve-2.0-2016.xml
-rw-r--r--  1 test  test   2.6M Aug 20 06:57 nvdcve-2.0-2016.xml.zip
$ grep -c "\*\* REJECT \*\*" nvdcve-2.0-2016.xml
1106

If you are wondering, why did I used the keyword "REJECT": This is the only way that there is a CVE and cannot find a CPE. For example:

$ grep -A5 "<entry id=\"CVE-2016-0001\">" nvdcve-2.0-2016.xml
  <entry id="CVE-2016-0001">
    <vuln:cve-id>CVE-2016-0001</vuln:cve-id>
    <vuln:published-datetime>2017-05-11T10:29:55.767-04:00</vuln:published-datetime>
    <vuln:last-modified-datetime>2017-05-11T10:29:55.767-04:00</vuln:last-modified-datetime>
    <vuln:summary>** REJECT **  DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: The CNA or individual who requested this candidate did not associate it with any vulnerability during 2016. Notes: none.</vuln:summary>
  </entry>

The reason why this happens, I have explained in this question: Categorizing CVE product name


How does github.com implement CSRF mitigation

Nonlinear workflow

The question seems to assume a linear workflow - i.e., user loads page A that has token A1; performs an action that requires that token; loads page A again, this time with token A2, and performs an action that requires it.

However, it is perfectly reasonable for users to have multiple pages open in the same session - you can "use a token" in one tab, then switch to another tab that was opened an hour ago, and click a button that submits a token that technically is much older than the one you just used. If the older token would have been invalidated, that would look as an obvious bug from the user's perspective.

Also, it's reasonable to use the back button, which may return to a cached version of the page with the old tokens. You can GET a form with a particular token, submit a POST request with this token, then remember that you need to change one more thing, press the back button (which shows the form again without fetching a new version) and then submit another POST request with (obviously) the same CSRF token that you just used. Again, this is a reasonable workflow, and it should just work, and invalidating the token would break it.

Some invalidation of CSRF tokens would be reasonable, but it should happen in conditions similar to session expiry - either on explicit logout, or a comparably long timeout; not on simply using a newer token, as within a single session it is reasonable for tokens to be used out of order and/or reused.


Can a file have the same MD5SUM but different SHA-1 results from different tools?

Can a file has same MD5SUM and different SHA-1 from different tools?

If the file has not in fact been changed in the meantime?

No. Not if both old and new hashsumming tools are correctly implemented. (I.E. if they are implemented according to the MD5 and SHA1 standards.)

I suspect (in fact I'm short of betting) that the earlier checksum was just misdocumented.


Why is my Windows 10 machine listening for 127.127.127.127:3939?

A quick TCP port search hints at some ant-virus application related port. Since its listening to the local host ip-address it may be two processes of an application communicating to each other via local host-only TCP sockets.

You can find out the exact process ID by running this command as Administrator:

netstat -aon | find ":3939"

That should reveal which program is using this port.

Edited after discovering that PID 4 uses the port:

Typically HTTP.sys opens a local port on behalf of a system service such as IIS, SQL reporting server, print spooler, etc. These will all show up as PID 4.

Refer to these answers https://superuser.com/questions/352017/pid4-using-port-80 and https://stackoverflow.com/questions/1430141/port-80-is-being-used-by-system-pid-4-what-is-that to identify and try disabling the service corresponding to this particular port.

You could begin by trying to stop the HTTP service and in the process discover which other services rely on it:

NET stop HTTP


That's not a DDoS but a brute force attack. They had a monitor looking for their target (you) investigating them. Once you tried to scan them, they halted in order to avoid further analysis.


If I understand you correctly, you are describing a hybrid cryptosystem.

As Natanael mentioned, GPG and PGP use the OpenPGP message format (RFC 4880) by default.
OpenPGP is a hybrid encryption system.
As far as I know, OpenPGP is the most commonly used format used today for email that is end-to-end encrypted. It supports efficiently sending the same plaintext message to many different recipients, more-or-less like multicast.

I don't know any better method for multicast encryption than hybrid encryption.

The original question uses the term "group key", which doesn't seem to match up with anything in OpenPGP.
However, I hear that several group key protocols have been developed for pay television encryption systems, such as
"Multicast Encryption: How to maintain secrecy in large, dynamic groups?";
"An efficient and secure group key management scheme supporting frequent key updates on Pay-TV systems";
and
RFC 2023: "Group Key Management Protocol (GKMP) Specification".

WPA also uses group keys.

Entire books have been written about this topic, such as "High Performance Group Key Management: A Way to scalable Internet Television"


Why does the NodeJS Crypto docs use CBC instead of GCM for RSA key-pair?

The Cipher-Block-Chaining Mode becomes problematic if your threat model includes an attacker who actively manipulates the encrypted data. This allows an attacker to flip specific bits in the cipher to flip the same bits in the resulting plaintext - a property called malleability. If not paired with a MAC to ensure integrity, CBC is not very secure.

When encrypting a private key to be stored on a local device, the only requirement is confidentiality. An attacker could flip specific bits, but it is most likely that this will result in the private key becoming unusable instead. CBC is still good enough at providing confidentiality, and without the AES-NI extension, it's a lot faster than AES-GCM, as you can see in the following graphic:

Source: kazoo.ga

To give a succinct answer: Node.JS uses AES-CBC because for this case, the extra benefits offered by AES-GCM don't matter and AES-CBC is usually faster.

In the above graphic, the performance of AES-CBC without AES-NI is used as 100% performance. The relevant other category is AES-128-GCM w/o AES-NI. Of course, if NodeJS supports AES-NI, then AES-GCM is a better choice.


A Pixie-Dust attack works by bruteforcing the key for a protocol called WPS. WPS was intended to make accessing a router easier, and it did - for attackers.

A WPS Pin consists of 8 digits - two Pre-Shared-Keys or PSKs. Each PSK has half the pin. To understand how a Pixie Dust attack works, you'll need to understand how the requests to the AP work:

1. Computer sends - EAPOL Start

2. Router sends - EAP-Request for the Identity

3. Computer sends - Responds with the Identity

4. Router sends - EAP request

5. Computer sends - EAP response
...

And it loops these requests a few more times before the credentials are sent.

However, during this process, your computer has been given the following:

Diffie Hellman Public key of the Enrolee
Diffie Hellman Public key of the Registrar
Two hashes - of the WPS PIN
Enrolee nonce and a derived authkey

;
Now in order to successfully bruteforce the previously mentioned PSKs, you'll need two more nonces - which are supposed to be randomly generated. And this is the most important part - since the random numbers are not really random but are derivations of the hashes (or are just zeroes) then we can bruteforce this key, even on a slow system! It will work if the implementation on the router is bad (which it is in most cases) and you should be able to find a list of vulnerable routers on the internet.

tl;dr: We bruteforce a badly generated key because of a flaw in how the random numbers are generated in many routers.


Combining wildcard and subdomain-specific SSL certificates

If the thieves man-in-the-middle connections to saas.example.com and present the wildcard cert, would the customer getting man-in-the-middled get any sort of SSL-related warning from their browser?

Usually not because the attacker presents a non-revoked certificate which is valid for the accessed host. The client would only reject the valid certificate if some kind of certificate pinning was used and the certificate did not match the expected public key.


CSRF methods: img vs iframe vs form/javascript

I can think of two major reasons why one might favour using img and iframe over a JavaScript proof of concept for the scenario you described above.

There is this common mentality that I see among members of the security industry that simplicity is key when it comes to building proof of concepts. You will often encounter people trying to build the shortest payloads to exploit specific issues. Based on personal experience, your proof of concepts tend to be easier to understand and to share with fellow security researchers (this isn't always the case though as we see with XSS polyglots [1]). On top of that, it is also fun to try to shorten your payload (see "Code golf").
When it comes to exploiting the issue, an adversary will probably want to cover as many edge cases as possible. Some users disable JavaScript in their browser which would render your exploit harmless. A non-JS-based exploit would solve this potential problem.


Generally ISO/IEC 9796-2 digital signature scheme is used in cases where the memory footprints of the underlying platform are lower or the data to be signed is very small. Ideally it is not suited for signing some documents etc. For signing documents in the PC environment one can resort PKCS 1 signature schemes with PKCS 7 signed data where we can have envelopes containing the data and certificate.
Lets assume a RSA Key Pair with modulus size of 128 bytes; typically with padding schemes the data which we can encipher to generate a signature is around in the range of 70-80 bytes. In 9796 the size of data which can be encrypted is slightly higher.

In 9796 scheme, the data either full or partial is part of the data which is to be encrypyted to generate signature which in normal PKCS 1 case, data to be encrypted is the digest of the actual data. In latter case for verification; a copy of actual data is required.

Now coming to certificates; in general PC environment we are used to X509 certificates which are bulky in footprint for constrained environment like smart cards or terminal devices. In constrained environment; instead of X509 certs a simple TLV based certificate is used which makes it easier for the reader to read the certificate. So when a certificate is presented in the 9796 scheme, the certificate is part of the signature. There are some digest also included in the data to be encrypted like a pattern of sort M1|Digest|M2. You can refer the 9796-2 specification for more information. I am taking the pattern as general description. Here M1 is recoverable part and M2 can be either recoverable or empty. If M2 is empty than the signature verification device needs the M2 through some other means. In this case the reader just needs the public key of the CA to validate the signature and extract the certificate. The digest in the pattern is digest over M1|M2 in some order. Usually EMV (Euro Master Visa) and other payment card industry uses 9796 schemes. Also many of Electronic Id cards uses the scheme.


according to the press release: https://www.absolute.com/company/press-releases/2009/computrace-by-absolute-software-now-supported-in-firmware-of-getac-computers/

Computrace software is embedded in the firmware of computers right at the factory for tamper-resistance.2 The stealthy Computrace Agent is capable of surviving operating system re-installations as well as hard-drive reformats, replacements and re-imaging.

Absolute Monitoring Center, allowing the Absolute Theft Recovery Team to forensically mine the computer using a variety of procedures including key captures, registry scanning, file scanning, geolocation, and other investigative techniques to determine who has the computer and how it is being used.

Yes, it would have access to:

VM's virtual harddrive file
Dump of the computers memory ... which would contain the VMs memory
All Network traffic from either the Physical or VM

They might have to jump through a few hoops to do some of this ... but it wouldn't be far fetched for all of this to be possible if they are tapping the firmware itself.


Can we keep our customer's X509 Certificate as BLOB on our server?

Edit: On second thought, this seems to be an xy problem.

Iff you store the certificate, that isn't a problem as that is just a veryfied public key, i.e. public information.

I do however suspect that you do not mean certificate since you also seem to need a password.

If you do indeed mean the private key: you should not keep it; you shouldn't have it to keep in the first place. If you do need to do things on behalf of a client, ask them to provide you with reasonable means of access for whatever service you need to run for them.

One might suspect that you do mean private key for an https certificate. Yes, if you are the hoster, you do need the private key for the https certificate - and it's not a personal certificate of the client, it rather just demonstrates control over the IP or domain - which you have as a hoster.

Since you seem confused about basic terminology, I'd advise you to not store any customer data and instead focus on understanding what you're trying to do first.


Is it possible to verify that a signature was made prior to the content of the document it is found on?

The answer to your question is yes, it is possible with inks to determine how long they have been set and perform a differential analysis to see how far apart the different inks were set. This may not be possible with all ink types, and the closer the attacker sets the ink after the initial signing will play a major factor. Another major factor will be the amount of time between the initial signing and the actual analysis.

The best case scenario for the attacker would be getting the signature, applying their forgery immediately, and then revealing as little about the document as possible. The longer they can retain the document and prevent the analysis, the better off they are. The inverse would be true for an analyst.


Is the following protocol a good method for encrypting a non-OS hdd?

It looks quite good for encrypting a computer disk where you will install your OS. Some comments:

You are filling the disk with random data by creating a temporary luks device, that you then fill with zeros. I would have used shred -n 1 /dev/sda to do the same, replacing your first 5 steps. I suspect shred may be slightly faster, would need to benchmark to be sure. Anyway, your approach would work, too.
You claim that "there's no chance to boot the system without the external device". I disagree, it would be possible to create an equivalent external device that is able to boot your system, as long as that the password is known. If you really want to force that only that usb device can be used for booting, I would include a key file in the usb device that is decrypted with a user-defined passphrase, then used as a LUKS key-file. That would require cloning that specific device, not only discovering your luks passwrod.
Booting from a separate media is better in that you can use a trusted boot device. On the other hand, this requires that you allow booting from external devices, which would make it easier to tamper with your machine (your disk is encrypted, but still). As a way to improve this, you could use a TPM to verify that you are booting what you really wanted to boot.
Another option would be to use a hardware security key instead of or in addition to your boot usb.
You don't mention it, but in the end, you would install the OS in the given partitions by pointing the installer to them as usual, letting it format those LVM groups.

Finally a few of warnings for anyone which wants to follow this:

This procedure will obviously remove any data that was previously on the device.
/dev/sda is the main disk of the computer. Most likely it is NOT the device you want to encrypt. topencrypt wants to use that one but you probably not.
Given that the above procedure wipes the main disk, it should be performed booting from another one (usually a live CD/usb).
Using an encrypted disk increases the risk of something going wrong and losing access to the data, making backups even more important to have.

Creating a LUKS partition for a non-OS external disk

The OP later mentioned that he is not interested in having OS data there at all, but only wanted an external hard disk that he would boot into his linux os.

This changes the procedure quite a bit, it becomes much easier as we won't need swap, lvm volumes for root and home, etc. A big filesystem on an encrypted container should this more simplistic need.

Note that in this case it is completely unlikely that /dev/sda is the hdd you connected. I will refer to it as /dev/sdX. You can find out the name assigned using lsblk, checking dmesg output, etc.

Creating an encrypted disk could be as simple as:

shred -n 1 /dev/sdX # Fill the disk with random data. This will take a while and destroy everything that was stored there
cryptsetup luksFormat /dev/sdX # Create luks container
cryptsetup luksOpen /dev/sdX external_disk # Open encrypted drive
mkfs /dev/mapper/external_disk  # Format the external disk

That's it.

Close the mapping with cryptsetup luksCLose external_disk and disconnect. If you know connect it again to your computer, your distro will probably automatically ask you for the encryption key to mount it, or will show it as a locked device that will ask the password you attempt to open it.

Should you need to mount it manually, you may do:

cryptsetup luksOpen /dev/sdX external_disk
mount /dev/mapper/external_disk /mnt # Mount on /mnt

Remember that the disk will have been formatted with an ext filesystem, in order to be able to write to the drive with your user account, you should change the permissions so that your user is able to write on it, for example: chown topencrypt /media/topencrypt/external_disk
(it would be the same whether it's encrypted or not).


The upgraded version of timthumb has many security mechanisms in place to prevent those vulnerabilities and the code has been more closely inspected after the discovery. I am personally using it on several sites, and would not think it's any less secure than any other alternative. However, it of course depends on the alternatives and I am not aware of any in particular.

There are no guarantees to security. There's always a chance that a new vulnerability would be discovered. But that applies to any product. I tend to think that products that did experience a security issue are likely to take security into account more so than those who didn't experience any issue. That's of course highly individual to the people, product, the environment and so on, so not something to rely on.

Instead I would focus on setting timthumb as securely as possible for your environment. For example, make sure no external image sources are allowed. In such configurations, I believe even the old version of timthumb wasn't vulnerable.


Is Google's objective to kill passwords justified?

These measures will greatly reduce the impacts, and or attempts to circumvent them. The issue with passwords are, no matter how much you try to educate anyone, it rarely works. Individuals prefer comfort over security, as indicative by making a password: "P@ssw0rd1" to meet complexity requirements. As long as there are passwords, people will keep creating passwords that are weak, and attackers will continue to break them. Moreso as the power of computing goes up, and pricing on creating a powerful machine to break passwords, goes down.

Psychologically, we want things right now. The moment we type something in. "Bandwidth is too slow. This page took 3seconds to load, it usually takes 300ms" We have slowly been groomed to receive instant gratification, and or, to perform tasks with lightning speed. "Have to log in to upload this report by X deadline." No one wants to spend the added time typing in something overtly long, and complicated. Forcing them to remember: "4%6DMoeTr,$^" won't work as the user will write it down. Forcing complex passwords leads to conformity: "Finethisismypa$$word1" which has not worked.

By Google and others using other variables, the attack surface becomes more difficult to tackle from an attack perspective. An attacker would have to know the proper set of variable to trick systems into authenticating. The issue I can see from the biometrics (machine learning) when dealing with typing will come via the following: "What happens if I break my arm, and am typing one handed", "what happens if I type my password one handed because I am on the phone or eating a sandwich." Swipes, same applies. What happens if I come back from a bar, and after a few drinks my swipes error out. Can I not make a bank transfer?

There is still a way to go including Google having to account/store even more data on individuals which leads to even more potential privacy abuses. "We know he/she is left handed, is likely a drunk due to the false positives every Friday night, and is a horrible speler!" (purposely mispelled). Any company looking to do away with passwords is on both the right path, yet also on a path to having too much information on an individual. Is it necessary? Yes it is. Cybercrime is billions of dollars in lost money, sometimes broken dreams (someone's account getting wiped out). Anything that can tackle this is on the right path


How to detect the NSA MITM attack on SSL?

and decrypted their SSL traffic by compromising a backbone router

No, that's wrong (but it doesn't impact the rest of the question). According to that claim, the NSA compromised a router that belonged to the target (not that it really matters). More importantly, compromising the router did not help the NSA decrypt the SSL traffic: all it did was allow the NSA to perform a man-in-the-middle attack on the encrypted-and-signed stream. If all the aspects of SSL had held, that attack would have been detected and the NSA would not have been able to decrypt legitimate traffic.

The decisive part of the attack was that the NSA could craft a fake certificate for Google. An SSL certificate roughly contains the following parts:

A description of who the certificate belongs to (Google)
The public key of that entity
A description of who vouches for the certificate (the CA)
Some mathematical magic that ensures that only the holder of the private key of the CA could create that certificate

It appears that the NSA knew the private key of the CA, hence they could create a certificate containing a different public key, which corresponded to a private key created by the NSA instead of the private key held by Google.

Since the fake certificate is different from the genuine one, it has a different fingerprint. (Note that this may not be the case for MD5 fingerprints: MD5's collision resistance is sufficiently broken to allow the creation of two certificates with the same fingerprint — but not to craft a certificate with the same fingerprint as an existing certificate. But no such vulnerability is known for SHA-1.) Therefore if you detect that the certificate's SHA-1 fingerprint is wrong, you know you are being actively man-in-the-middled.

This is of limited practical importance, because you have to be able to retrieve that SHA-1 value reliably somehow. Where are you going to find a trustworthy connection to retrieve these fingerprints?

Spreading the verification across several parties
is one way to resist the compromise of a small number of CAs while allowing browsing hitherto-unknown sites.


Deriving digital signature key pair deterministically from an arbitrary secret

It's possible, but there are some caveats to be aware of.
At first glance, it might seem that ECDH lends itself well to this, as an ECDH private key is nothing more than a 256-bit value.
So, in theory, you could simply take the SHA256 hash of your password, which will return a 256-bit value, and use this as the ECDH private key.  Then, the ECDH public key can be derived from the private key.  However, if your password is easily guessed, or appear on list of known passwords (such as rockyou.txt), your private key may be easy to crack using a rainbow table.
To mitigate the above problem, keys are often derived from passwords using a random salt, and many rounds of hashing (e.g. PBKDF2).  However, in your use-case, this poses the problem of where to store the salt?


Revealing your IP address doesn't compromise the security of your machine. If an attack on your machine is untargetted (i.e. the attacker just wants to use it to send spam or fishing emails, or as a proxy for targetted attacks), your machine will be scanned at random, not based on the IP address that may be posted in a forum. If the attack is targetted, the person conducting the attack will usually know enough about you to find out your IP address anyway, the real security comes from not having a vulnerable machine.

On the other hand, revealing your IP address compromises your privacy. It usually reveals what general geographic area you are accessing the Internet from, and who your Internet provider is; depending on your Internet provider, it may be possible to locate you quite precisely. It may also be possible to correlate your IP address with one online identity with your IP address with another online identity. So it's often not something you want to publish to the whole world.

Any computer you directly connect to knows your IP address by construction. As a website designer, treat IP addresses the same way you'd treat any other private data such as name, age, gender, street address, telephone number, ... Do not expose them to anyone who isn't a site administrator. Remember that webserver logs will usually contain IP addresses for every request, so protect the logs like you protect your user database.

Note however that it often isn't difficult to obtain someone's IP address online. All you have to do is host an image on a server that you control (costs <$10/month), and arrange for the person to browse that image in their browser. The IP address of everyone who viewed the image will be in the server logs.

This is why email programs usually require you to confirm whether you want to view an image, and one of the reasons why many social sites require all images to be uploaded to their own servers.

As a user, if you're really worried about revealing your identity, use a proxy. You trade privacy for bandwidth and latency, as well as privacy (the proxy knows what sites you've visited). You can go further and use Tor, which is a “split” proxy where different entities get to know your IP address (the entry node) and what site you're visiting (the exit node); you trade more bandwidth and latency for a bigger privacy gain.


When you setup a new hardware token, you're usually presented with one of two options: you can either let the token generate a new key or you can program it with a key you generated outside the token.

By design, keys that are stored by a 2FA token cannot be read out of the token. That doesn't mean that in the future, someone can't find a vulnerability in the design that makes this possible.

However, if someone has a physical access to your token before they reach you, there's a much easier attack vector rather than tampering with the token, which is to simply swap the hardware token itself with a fake one that is designed to send the keys out to the attacker.


First thought is that it does seem to be quite a lot of tokens and it does beg the question if it's indeed a requirement for the authorization server to issue so many specific tokens or if less tokens with more broader applicability could suffice.

However, focusing on your question...

Besides the sessionStorage there is also localStorage which would tackle the issue of sharing between multiple tabs.

As you correctly pointed out, storing between cookies and web storage does present different security challenges, one being, that web storage is vulnerable to XSS while an HTTP-only cookie is not. However, a HTTP-only cookie used for authentication is vulnerable to CSRF because it's automatically included by the browser, while a token stored in web storage is not.

At the days end, choosing the right storage is choosing the pros and cons that best adjust to your specific scenario. For a better idea on the impact of your choices check this answer on StackOverflow. It covers the pros and cons of the following options:

Option 1 - Web Storage (localStorage or sessionStorage)
Option 2 - HTTP-only cookie
Option 3 - Javascript accessible cookie ignored by server-side

For the ones that don't follow links, I include the conclusions part inline:

  My recommendation for most common scenarios would be to go with Option 1, mostly because:

  If you create a Web application you need to deal with XSS; always, independently of where you store your tokens
  If you don't use cookie-based authentication CSRF should not even pop up on your radar so it's one less thing to worry about

  Also note that the cookie based options are also quite different, for Option 3 cookies are used purely as a storage mechanism so it's almost as if it was an implementation detail of the client-side. However, Option 2 means a more traditional way of dealing with authentication; for a further read on this cookies vs token thing you may find this article interesting: Cookies vs Tokens: The Definitive Guide.

  Finally, none of the options mention it, but use of HTTPS is mandatory of course, which would mean cookies should be created appropriately to take that in consideration.


Spurious SSL Certificates when accessing sites through enterprise network

Yes, your Network Admins are spying on you. The trade off is that if they do, you can't rely on the identity of any remote party you connect to via TLS; but if they don't, you might be taking advantage of the confidential channel to download malware, post proprietary documents to competitors or whatnot.

When I'm working for companies that use this type of filter, I take the filter for what it is: the IT department is assuming responsibility for the identities of remote parties I connect to. I therefore use https connections to work-related services as I normally would: if their filter gets it wrong and connects me to a fake CRM, for example, that's a decision that my IT department took on my behalf.

I avoid anything where I care about the identity of the remote end like online banking. I would never ask my sysadmin in real life whether she thought some random server was owned by my bank, I'm not going to start doing it via a proxy device either.


SQL injection possible with hidden GET parameters?

I'll try to answer one question at at time,

  Is it possible, in this case, to perform SQL injection? I found
  extensive tutorials online explaining how to inject normal GET
  parameters. However, if I'm not much mistaken, .htaccess is used to
  rewrite the URL so would that prevent (or change) the procedure?

Yes, it is possible. Since the query is expecting to return one result, you can force the current query to return no results (check point 3) and then make a union with another table (for example the users table) and return a single row at a time.

  Secondly, since the browser encodes special characters (for example
  spaces to %20), doesn't that mean MySQL will get something like
  WHERE id='1234%20AND%201=1 and cause a syntax error?

No, the characters are only encoded in the url, when the String reaches the server it will be as if it wasn't encoded.

  Why did it yield the same result even when I tried adding AND 1=1
  and AND 1=2 at the end of the id parameter?

You're getting that error because the query is returning false, maybe because the way the query is constructed and you're not injecting on it right. For example when you say AND 1=2 you're making the condition false and no rows are returned. But better read this to understand better.

Try to put -- after, like id=1234 OR 1=1 --, to try to avoid that error.

  Why did id=1234%20AND%20'1'=2 yield ...to use near '1''' at line 1?
  I only put one single quote around 1 yet the error seems to indicate
  there are two additional single quotes after 1?

It may be the format for the database to return the errors, if you notice, in the other errors, it is adding '' in the end also.

  The web browser (I'm using Google Chrome) doesn't seem to encode the
  = sign, yet manually changing it into %3D doesn't seem to make a difference in the outcome. Why is that?

Look at point 2. When the String reaches the server it will be a = in any case.


How to create your own RBL DNS Blacklist to prevent spam

You can do it with a standard dns server, but I have seen rbldnsd which appears to be made for this purpose - the main feature being that it allows you to blacklist sites very easily by adding them to a mysql database.

Found a quick instruction page here.


How to encode a username in PKIX certificate?

Faced with this question, Microsoft answered the way they are accustomed to: with a Microsoft-specific extension. They defined the User Principal Name, which is actually an OtherName element, the UPN being identified by a Microsoft OID (1.3.6.1.4.1.311.20.2.3) and encoded as an UTF8String (as succinctly specified there). The format of the string mimics that of an email address, in that it consists in an account name and a domain name, joined together with an '@' character.

It is noteworthy that though the UPN looks like an email address, it is not meant to be used for sending emails; and, correspondingly, Microsoft did not use a rfc822name element, because such a name conveys email-based semantics (in particular when the certificate is used with S/MIME) that UPN are not supposed to embody.

The "X.509 way" to encode a name in a certificate, whose format does not match the predefined categories, is to do it along the same lines Microsoft did: use otherName, with an OID of your own, and define your own syntax. Of course, such a name will be usable only by your own software... Although you may decide to reuse the Microsoft UPN format, and thus (possibly) gain some compatibility with Microsoft software (the UPN's goal is to map a certificate onto an Active Directory account).

The really important thing is to determine which software systems will have to deal with your "username". It is useless to encode a username in a certificate if the systems which must decode that username don't know how to do it. For instance, suppose that the username must be used by an Apache-powered Web site, the client certificate being presented at the SSL level. The documentation, in particular the SSLUserName configuration directive, shows us that Apache may be set to use some specific certificate fields as "username", among the exhaustive list of environment variables maintained by the SSL module. If you are in that situation, then you will have to put your "username" in one of these fields, not in some otherName with a syntax of your own.

From looking at these fields, I'd say that your best bet would be "UID". That's one of the components of a Distinguished Name, specified in RFC 4519 under OID 0.9.2342.19200300.100.1.1. It is basically a free-form string, and Apache's mod_ssl knows how to extract it and turn it into a username with:

SSLUserName SSL_CLIENT_S_DN_UID

As a part of a DN, this would go in the subjectDN field directly, not into a Subject Alt Name extension. (This raises the question of why Microsoft did not use that "UID" field for their UPN; my guess is that they wanted at some point to use the complete subjectDN as a path in some LDAP directory, and thus could not add extra fields at will in the DN.)


Does CSRF work when the target site is not open on a tab?

When you log in to example.com, your browser stores a session token in a cookie. This session token uniquely identifies your logged-in session with example.com. Every time your browser makes any request to example.com, that request includes your example.com cookie data, including your unique session token.

With that in mind, consider the fact that a Web page can make your browser attempt to fetch any resource on the Web, e.g., through <img> or <iframe> tags. If a page includes a tag that asks your browser to fetch a page from example.com, the fetch will include your session info. The request is done in the context of your logged-in session (i.e., the fetch is being done as your logged-in example.com user account).

If the fetch of the example.com resource causes some action, then you (and the site) have fallen victim to a CSRF attack.

To answer your question directly: no, you do not need to have an example.com page open; you only need to have a valid example.com session token in your cookies.


Does this method of password confirmation risk encrypted file integrity?

Yes, this is a valid method of password verification.

A disadvantage is that an attacker now knows that the plaintext "password_is_correct" corresponds to the last block in the ciphertext. Fortunately, AES is not vulnerable for known-plaintext attacks.

PGP also checks the decrypted data, but it uses properties of a random block instead of a fixed string. Another way that is often used incorrectly is to verify the padding of the message. This can make a padding oracle attack possible, although this does not apply to your situation.

Another typical way is to store a hash of the key in the message, so that the password can be verified before decrypting the message.

There are some other things that can be improved with your script:

Use SystemRandom to get the IV, as normal random is not cryptographically secure.
Use a real key derivation function such as PBKDF2 instead of SHA256 to derive the encryption key from the password.
Store a HMAC of the encrypted text and verify it before encryption. CBC is vulnerable to a bit-flipping attack.
You may want to also encrypt the filesize field.


Cracking a password Protected pdf file using John the ripper

Generally the target hash you want to break in the case of a PDF is the user hash, which is derived from the user's password. A PDF will do two things when a password is entered for an encrypted PDF -

It will derive a symmetric key from the user password. This is the key that the document is encrypted with.
It will derive a hash from the password and will compare it to the user hash in the documents metadata to check if the password is correct.

PDF is strange in that it actually derives the symmetric key before it computes the hash, in fact the symmetric key is used in the computation of the hash. The process of producing the hash is as follows:

Derive the symmetric key from the user password.
Concatenate the following values and pass the result to the MD5 hash function:

A 32 byte padding string (defined in the spec)
The 16 byte document ID (contained in the documents metadata)

Encrypt the output of the MD5 call via RC4 with the symmetric key from step 1.
Do the following for i = 1 to 19:

Create a new RC4 key by XORing every byte of the symmetric key from step 1 with i.
Take the output of the previous RC4 call and encrypt it under the new RC4 key.

Append 16 bytes of arbitrary padding to the output of the last RC4 call. This is the user hash. (It's not clear why the user hash is padded at all, since the comparison to validate the user password throws out the padding bytes of the user hash and just looks at the first 16 bytes.)

What I would assume that John the Ripper does is it will feed passwords (defined by whatever rules you give it to generate passwords) into the above algorithm until it computes a user hash that matches the one in the document metadata (i.e. the hash that you provided). Since the hash derivation uses only MD5 and RC4 (and not a lot of rounds of either) it is quite easy to try a lot of passwords in a short amount of time, so PDF is quite susceptible to brute force and dictionary attacks. In fact the whole algorithm is rather bizarre and doesn't instill much confidence in the security of password protected PDFs.


Trustwave SpiderLabs wrote up a blog on analyzing malware with hollow processes -- https://www.trustwave.com/Resources/SpiderLabs-Blog/Analyzing-Malware-Hollow-Processes/

Cuckoo Sandbox, a popular and free, open-source software (FOSS) automated malware analysis engine can also be leveraged for working with hollowed processes -- http://journeyintoir.blogspot.com/2015/02/process-hollowing-meets-cuckoo-sandbox.html

and the mother-of-all articles on process hollowing has been summarized here -- http://marcoramilli.blogspot.com/2016/05/process-hollowing.html


How unsecure would I assume old PHP code is?

Well first of all its an assumption, so assume away!

Your talking about the PHP code's security, so can we ignore the outdated versions of the stack: Linux, Apache, PHP, MySQL. All of which you should be able to pull up a number of exploits for (knowing the version) via Google. We can then talk about the PHP application. The code is going to be as secure as it was written.

You mentioned some kind of code generator was used to create it? Which one? I recommend you find out, and get some samples of what it generates.
Considering the age there is a good chance it doesn't take into consideration of few common vulnerabilities: XSRF, XSS, SQL Injection.

They don't call it "Pen Testing" for nothing.

I'll try to be more helpful... by giving you a bunch of questions for you to find answers to.

What kind of information do these sites collect? Does the CMS side of the site have logins?  Does the site use session cookies to authenticate?
Try logging in and have a look at the network logs with the inspector in Chrome/FF.

Also what kinda of attacks are you worried about? What information is stored in the site that is sensitive? Are the servers inside a network that contains other sensitive data or assets? Try to model your potential threats and what worst case scenarios they could create.


gpg does not require passphrase to decrypt

This is due to gpg-agent temporarily caching your password. You can easily disable caching.


Google login button - what prevents an rogue app from stealing a token?

When the user selects an account to sign in with, they are taken to a login page (if not currently logged in) and then/or sent "back" to the app in question, along with the SSO token. I say "back" because the user will be sent to the URL that was specified when the app was configured for SSO. That won't be the attacker's site; the attacker won't be able to see the SSO token.

Google (or other IDP) could also attempt to check where the user came to them from (checking the Referer header) to ensure that it's not some other web app spoofing the legitimate app's client ID, but that is probably not needed.


How to an "emulate" man in the middle attack for SSL and TLS?

That doesn't make much sense. You are asking a XY problem.

First of all. TLS is a just a new set of the SSL specification:

TLS 1.0 would be SSL 3.1
TLS 1.1 would be SSL 3.2
TLS 1.2 would be SSL 3.3

The name change was due to politics, and has a lot of confusion since (eg. users enabling only SSL 3, thinking it's the latest version, while it's te oldest).

So you first need to decide what to compare. SSL 3 vs TLS 1.0? Against TLS 1.2?

You would probably concentrate in the differences SSL 3.0 vs TLS 1.0, and then you could also state some improvements of the newer TLS versions if you wish.


Would using Google reCAPTCHA allow Google to cheat?

Yes, you are correct. The administrators running reCAPTCHA could request a CAPTCHA from your site and then perform a look-up to see which CAPTCHA was generated for your site and therefore the expected string which validates.

The trade-off is that 1) they are probably trustworthy not to be doing this because of the potential damage to reputation if/when caught and 2), it's still probably better than you could implement yourself.


You might find the solution to your problem in this answer on superuser:

Some more information on a big related to your issue here.


Can someone know my geolocation by replying to Whatsapp message?

No you cannot gain the geolocation from a message you have sent someone via what’s app directly.

You can gain this if the message then proceeds to get you to do something else, such as open an app/link which then sends the receiver the location information (varying degrees of accuracy such as IP or GPS depending on app capabilities).


Which signing key should I use for certifying other peoples public keys: master or subkey?

The four possible key "usages" are

Certification: signing other keys
Signing: signing data
Encryption: decrypting data
Authentication: signing authentication tokens

When you look at your key using --edit-key, you find the usage listed behind each key and subkey. By default, all that are supported by the key type are attached to the master key (so, RSA defaults to CSEA, DSA defaults to CSA as DSA keys should not be used for encryption). There are special key types that are more limited than their algorithm (e.g. "RSA (sign only)" that supports only CSA).

When creating a subkey, a key usage is assigned to it in the signature binding the subkey to the master key; this delegates this functionality to the subkey, which also becomes the default key for the respective operation, while the key usage is hidden from the master key.

Certification cannot be delegated to a subkey, so you will always need your master key to sign another key.

Signing can be delegated, and the newest valid key with a Signing delegation is automatically used for signing, unless another is forced by specifying the key to use with an exclamation mark in front.

Encryption can also be delegated, and the newest valid key with an Encryption delegation is automatically selected on the sender's side, unless another is forced with an exclamation mark.


Threat modeling: why would a https remote endpoint be prone to privilege escalation?

If someone compromises the proxy, they can attack your web app.

If they're on the same machine (inside all the same boundaries) then this matters less, not more.  But the proxy is probably more exposed to attack.


With Basic Authentication the username and password is send with each HTTP request to the server. But, the browser will not ask you again and again for each request because it simply uses the same credentials you've already entered as long the authentication succeeds.

This is similar if you give somebody the key to your house. You give the key once and the person (browser) will use it always to open the door (i.e. authorize against the server). Only if you change the lock (i.e. change password or similar) the original key will not work any longer and the person needs a new one. The person does not enter an authorized state in any way, it is just that the person has the key matching the lock.

EDIT: since the comment showed that it was not fully clear. The server never trusts the browser unless it can provide the authentication credentials. Thus it will not help to modify the browser. This is the same with the lock in the door: it will never open just for a person no matter how this person looks like. Instead the lock will only open for the person having and using the correct key.


The basic idea is probably that internal clients just use the mail server of their specific mail provider which is configured in the mail user agent. Whereas spam tries to deliver directly to the MTA (mail transfer agents) of the target domain. The configured mail server does not need MX lookups (just normal A|AAAA lookups) while the delivery to target domains MTA needs  MX lookups. And spamming lots of different domains thus causes lots of different MX lookups.


Access via link in Email - How can I make this most secure?

Is the added security the 2nd option delivers worth the longer process, in your opinion? I know this is a subjective question, but your opinion means a lot to me.

You correctly saw the security it could cause with the browser history. Only you can determine if it worth it.

However, instead of some random string sent by email, which will mostly force the students to find the email upon each connection, you may ask for some information they may already know or is more easily reachable to them (last numbers of the student ID, something like the birth date, etc.).

  If you think the 1st option's better, how long should the access key be?
  I want to embed the student ID and the project ID inside it, so I was thinking about using JWTs, but they are 220 characters. Is it too much? (URLs can contain up to 2000).

If possible, I would avoid to put any information in the access key but use a random string instead. Then, on server-side, you can have a database which will associate this random access key to the information you want (student ID, etc.). By this way, given one link, it will not be possible for the students to guess other valid links.

Concerning the length, around 20 characters as you have now seems fine.

I think this also answers to your two last questions.


Timing attacks in password hash comparisons

The first algorithm is sensitive to timing attacks, while the second looks better (but I don't know for sure if it's vulnerable or not). However, there is a bug with potential security implications in the second version: What happends if the two strings have different lengths?
Timing attacks are a real security issue that it is reasonable to be worried about, so you are right to bring the issue up. I could partly agree with your friend in that it is more important to use salt and a good hashing algorithm. This however does not mean that timing attacks are not important or should not be taken seriously. They should.
However, in this case, it is not obvious how an attacker could pull off a timing attack. Since the input (the password) is hashed with a salt, the attacker probably can't freely control what any of the compared hashes will be. That means it might not be possible to search your way to a matching hash. But all this depends on how the entire system is built, not just on the string comparison algorithm.
One good way to deal with all of this is to use a good library for the hashing. A well written library should take care of both salting and defense against timing attacks for you, without you having to go through the hassle to write all the code yourself.


Edit:  I am glad I get to edit this to add to my answer a bit, because after happening to read it again a minute ago I realized how far from really answering your question in a direct, useful way I came. What I said below yesterday was not wrong, but let me add just a tad more upfront to actually start to answer the question/s you raised & tie in what I wrote yesterday. So:

First, a requisite disclaimer:  From your standpoint you should not view me as you would a QSA or other compliance professional engaged by you in your paid employ and highly familiar with your specific circumstances.  From your standpoint, you should treat me as some guy on the Internet who may or may not know what he's talking about, and who you probably should not rely upon your sole source of information and advice about any important point.

Okay, so...

Let's start with this: those five servers you noted?  You very likely don't need any of them.

Why?  Well, here's the thing:  many of the PCI Requirements, as you may have intuited, aren't actually written with the small business owner's situation--especially the single-person small business owner's situation--in mind.  Rather, many of them are really directed toward mid-sized and larger businesses. The complex thing, however, is that there's no actual, one single place in the Requirements that says which ones apply to everybody and which ones apply to only to larger entities with more complex operations to monitor.  The reason behind that actually makes a little sense: some small businesses may actually use or run certain elements or capabilities that are typically found in larger firms and implicate some additional security considerations. But this not-really-clear approach can, in my experience, create some undue consternation among business owners when they start reading about how they need to take measures to protect equipment that they don't have.

Now, don't get me wrong: a small business, even a one-person small business, is not by any means exempt from the need or duty to comply with most specific Requirements.  You don't get to store unencrypted card data, or run your PCs operating systems' unpatched, or anything like that.  But there is at least a little bit of a "sanity test" element involved about whether a given Requirement applies to you. Lets go over one example: If you run a single-person business that you use a single Windows PC with a POS application on, what does Requirement 6.1 require of you? If you have Windows set up to automatically download and install patches, must you still "Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”)..." Windows vulnerabilities? Even if you were super-motivated to read over Microsoft's vulnerability bulletins for each month's announced security updates by the time they are released and you've read them and rated them (somehow) your lone Windows PC has probably already installed the security updates that have fixed them? (Now, on the other hand, if you were a security team with a huge national retailer might find that a lot more relevant.)   What about, say, Requirement 12.10.5?  Do you need to develop a written response plan and then "[d]evelop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments." if you have a single-operator business?

Obviously not.  If you look at your SAQ D self-questionnaire forms you'll see the "Not Applicable" column on there besides "Yes", "Yes, with Compensating Controls" and "No".  Small businesses can expect to make good use of that column. In particular, a lot of Requirements that apply to the types of servers that you listed in your question simply do not apply to you, a business operator who neither has any of those servers nor any need for such servers.  it is not the intent of the PCI Requirements, we must assume, to make you buy additional computers for your operations soley so you can put certain measures into effect to protect them and tick a "yes' box on the SAQ form.

But what about things that are less clear cut?  Requirements that seem pretty oneous for (let's say) a one-person, one-computer small business but which sound  like possibly relevant important controls?  This is where a combination of being willing to rely on a common-sense understanding of what "Compensating Controls" you can rely on in real-world security and put on the SAQ with a straight-face can prevent you from needing to, for example, necessarily deploy a network-based Intrusion Detection System or dedicated file-modification monitoring software.

More about that in a bit.  But first there's an important technical question to answer before almost any other: In your payment setup, is credit/debit card information first encrypted while it's still in the card reader or terminal itself, such that your attached PC with your Point-of-Sale software on it never even sees unencrypted vital card info at all? Or is that card information passed from your card reader/terminal to your attached POS machine "in the clear" where software on the PC first encrypts it before sending it out over the Internet? Because on the outcome of that question rests two things: the kind of PCI questionnaire you should be filling out (SaQ-P2PE vs. SAQ D) and the degree of measures you need to be implementing to provide a security environment that could legitimately PCI scrutiny. (As well as, you know, actually protect your customers' financial information.)

Let's start with your card reader or terminal.  If you have the right one, it can make a huge, huge difference in the hassles you'll have to deal with in terms of PCI compliance.  Why? Because of the existence of "on-swipe", card-reader-to payment-processor, end-to-end encryption.  This is, by far, the single most important issue there is when it comes to both your PCI compliance and the actual quality of security with which you will safeguard your customer's card information.

Why is that so?  Because with on-swipe encryption your customers' vital debit/credit card information is encrypted before it ever leaves the card reader and hits your systems.  It is decrypted only when that bundle of information hits your payment processor's infrastructure after traveling over the Internet.  In other words, whatever security weaknesses or flaws, even active malware installations on your Point-of-Sale systems (which is where payment information still gets first encrypted in most setups right now, unfortunately), become irrelevant.*  The in-reader encryption means that you, your equipment, and any card-info stealing malware that may reside in your equipment, simply have no electronic access to the information a crook would need to counterfeit a customer's card or abuse a customer's card number. If Target, Kmart, Home Depot, et al. had had end-to-end encryption in place and properly configured exactly no cards could have had their info captured by Point-of-Sale malware in the breaches that have so rocked the American retail payment space.  And--most directly applicable to your question-- the PCI requirements for a merchant who has o- swipe/end-to-end encryption setup are much, much shorter than the normal rules and entail vastly less expense and sophistication to comply with. (And those rules that exist focus entirely on whether you've got the encryption setup properly and on a few non-technological policy areas.)

How do you get on-swipe/on-reader encryption?  Well, you will need to call your payment processor and talk with them about replacing your current card reader with an encrypting card reader.  For the last very small business I did work for, less than a year ago, its payment processor had a Magtek reader (this payment processor just happened to partner with Magtek; there are other good makers out there also) available for about $90 per reader; setup entailed going over a configuration process over the phone with customer support for, oh, about 10 minutes.  Before buying the new readers we also called the company that made the POS software on the standard Windows PCs we were using, just to be conservative about avoiding conflicts; no problems. Installation and activation went very well, and my client since has been running as reliably and with much better security than as before.

Alternatively, if you might be interested in switching over to new payment offerings from Square, Amazon, and Paypal all of their now-shipping readers come with on-swipe encryption built-in.  And if you're looking at this October and thinking about getting an EMV/chip-card reader to meet the informal, not-a-deadline deadline for supporting that standard almost all of the dual EMV/magnetic stripe terminals you will see will come with baked-in encryption for magnetic swipe card transactions. (But check before you buy.)

So...yeah. That would be my guidance (as someone who, in a legal sense, you should not rely solely on for guidance.  Just a reminder/disclaimer). But yeah, encrypt your card data at the reader.

*And yes, I suppose maybe I go a little close to saying on-swipe encryption is a magical cure-all of some kind. In information technology you should always, always do some defense-in-depth stuff (like making sure your OS & program security patches are routinely downloaded and applied, being cautious to some degree about the programs you install on your PCs, running with a decent anti-malware program on, etc.)  But in-reader encryption is really a big, big deal.

tl;dr  Get an encrypting card reader, set it up properly, and make compliance much easier and your customer's credit/debit card info safer.


What's the difference between frame-ancestors and child-src?

If someone else is interested, given two sites A and B, if B has an iframe of A:

B
+-------------+
|             |
|   A         |
|   +------+  |
|   |      |  |
|   |      +-------> frame-ancestors B;
|   +------+  |
|             |
+-----+-------+
      |
      |
      +------------> child-src A;

A's frame-ancestors must contain B
B's child-src must contain A

So, frame-ancestors is used when you want that a site is able to load your site in an iframe, while child-src is used when you want to allow your site to be able to load a specific site in an iframe.