OAuth 2.0 authorization code flow vulnerable to "shoulder surfing"?

Is there anything the client (or the corresponding back end) can do to
  prevent this attack?

It seems that the OAuth 2.0 PKCE extension is what I was looking for.
As explained within this thread, the PKCE extension prevents a leaked authorization code from being useful to an attacker.

This is achieved by exchanging a (e.g. user session specific) secret with the authorization server, not only when redeeming the authorization code (similar to the default client secret), but also when creating the authorization request, so that the authorization server can verify that during the whole process the secret (and therefore session) stays the same.


How do we exchange public key securely in a DV SSL connection?

If I understand your question correctly you attempt to make the encryption stronger by adding another encryption layer on top of SSL. And you want to do this since you believe that EV certificates provide a stronger encryption than DV certificates but you cannot get an EV certificate.

If I understood you correctly then you are having a wrong understanding of SSL/TLS: the strength of the encryption does not depend on DV vs. EV certificates. The only difference between these is that there are fewer issuers for EV certificates and that these issuers check the identity more thoroughly of the party applying for an EV certificate. This means, there are no real technical differences which affect the encryption strength, but mainly organizational ones. One difference is though that browser tend do enforce revocation checks on RV certificates but often not for DV certificates.

But due to this organizational differences the chance is higher that somebody gets a DV certificate for your domain, for example by compromising your site, DNS or email for a short time. Thus you might be inclined to increase the trust in your peer by adding another protection layer. Only, the way you envision to exchange a key pair will not work since this would use the connection you already distrust. Instead such information would need to be provided either out of band (like send your certificates key in a really secure and trustable way to the peer) or by doing trust on first use (TOFU), i.e. assume that the first contact will be not compromised and exchange for example the expected key fingerprint for all future connections using HPKP.


You are performing a SYN scan or TCP connect scan (depending on your account permissions). With those scan types, you can receive the following port states based on the results of the TCP handshake:

open: An ACK packet was received, indicating that the connection was accepted.
closed: A RST packet was received from the host or firewall, rejecting the connection.
filtered: No response was received when attempting to connect to this port.

It is also worth noting that Nmap utilizes half-open scanning in the SYN scan mode because it never completes the TCP handshake. The idea is that this is more stealthy because logs often record when a connection is actually established.


Securing user postal address in a database?

As you mentioned, password hashing is a great way to secure a client's password in a database (if done right). However, if you/your app needs to know the data that is being hashed then hashing alone cannot work as you need to encrypt the data.

I assume you are concerned with data breaches themselves (attackers gaining access to the database and thus 'seeing' all this plaintext info). If this is the case, having a strong and secure (encrypted) database will be a life[money]-saver assuming the decryption keys are not also compromised...

Here is an article on how to encrypt sensitive data properly.

Here are some common mistakes.

Also, just because you 'see' Amazon's data (the addresses) doesnt mean it was stored in plain-text, it just means that -like you said- it is decryptable.


Access Control for REST APIs - OWASP recommendation

Background
Lets start from the top here. Your server receives a request:

Hi server,
Can you do X for me?
- Jane

Access Control is when the server checks to see that Jane is actually allowed to do X before processing the request. Generally speaking, all apps will have some endpoints that need an access control check -- maybe Jane is not allowed to delete records from the DB, or maybe Jane is not allowed to change settings of Bob's account, etc.
OWASP's point is that in an old-school app, when the user logs in, you might build a session info object telling you who the user is and what permissions they have, and keep that in server memory until the user logs out. Obviously that does not scale with modern cloud architectures.
JWT To The Rescue!
The key part of that OWASP quote is (emphasis mine)

user authentication should be centralised in a Identity Provider (IdP), which issues access tokens

Take anything that your microservices need to know about the user (ie anything that you would traditionally have put in the sessionInfo object) and stuff it in a JWT, hand it to the user, and have them hand it back with each REST call. Omitting the crypto parts of a JWT, the claims you care about might be:
{
  "sub": "48",
  "name": "Jane",
  "admin": true,
  "exp": 1621004706
}

Now, by unpacking the JWT from the request, microservices have everything they need to make an access control decision; no network calls needed! Trying to delete data? Do they have Admin: true? Trying to change Bob's settings? Are they Bob?
To make this all secure, we rely on the fact that JWTs are cryptographically signed (and sometimes encrypted, but that is optional) by the IdP. So to make this whole thing work, the only piece of info the microservice needs is the cryptographic key to verify the signature on the JWT. This is generally static, so you can stick it in config data or whatever. If the IdP is external (say you've integrated with Google or GithHub's SSO service) then the JWT verification key will be an RSA public key. If your IdP is an internal component of your app, then you can simplify a bit and use a symmetric HMAC key where the IdP and the microservices all have the same "JWT secret" in their config.
Service-to-service
Question from comments: is this model applicable for a service-to-service API?
Sure, why not?
Your client, even an automated one, will typically have some sort of long-term credential, typically an API key or a TLS client cert. You still want to make the client authenticate against a central IdP for a number of reasons:

The long-term credential usually does not carry all the meta-data. So something in your backend needs to look up the associated meta-data.
What if that access changes? Say you're auditing your config and realize you gave that component wider DB access than it really needs, or heaven-forbid someone accidentally posts that client secret key in a public git repo and you need to revoke it.

Doing the full access control check against the DB on every HTTP request is really expensive, but issuing a JWT with an expiry timestamp and forcing the client to re-do the /auth/login every 15 mins / 1 hr / 24 hrs is usually a reasonable security-performance tradeoff.
In some simple cases you may not have any meta-data and you just want to check that a request is coming from another authorized component; basically a "Are you me?" check. In these cases I've seen each component get a copy of the same symmetric JWT and just create themself a token before each request.


Are there any security risks associated with having static files on the server be publicly available?

There could be risk if any of the static content is customer data or PII for example things like personal photos , scanned in drivers licenses , medical images like xrays, completed user forms scanned in, etc.

If that data is only accessible behind a login screen normally but then you dump it into a publicly accessible CDN or AWS bucket for example now you have an issue of data leakage.

I would not be worried about HTML , CSS, or JavaScript as none of that should contain the keys to your kingdom anyways. That's all stuff you expect to be accessible client side and so you treat as public already.


Finding out the password or bypass Linux password for home encryption?

Unfortunately, no. The only password that can decrypt that file system is the one you chose when you set up encryption in Ubuntu.


Can firewalls detect and block outgoing by protocol

If the IP is static you can block using a firewall port 443 to/from the IPs you want to block. Otherwise, you are looking for an IPS like Snort https://www.snort.org/ You can use it to configure a specific rule for blocking a signature or pattern of SSH traffic with whatever other parameters you might need.


Use TPM2.0 to securely decrypt the hard drive in Linux -- unattended

On a Linux system, you can use clevis to "bind" a LUKS volume to the TPM2, and decrypt the root filesystem automatically in your case.  For example:

clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"0"}'

or

clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"0,1"}'

You will need it to already be encrypted and have a passphrase, which the command above will prompt you for.  You can leave the passphrase as a backup or remove it afterwards.

I'm not sure about using the PCR0 value itself as the key, since in my limited experience that value is pretty easy to access. I don't believe that is how "sealing" data against a PCR works but I don't know the exact relationship between the PCR value and the sealed value.

I have used clevis to bind a LUKS volume to the TPM2, and automatic decryption on boot-up when it's the root filesystem.  I encrypted the device during install, and had success binding it manually and in a kickstart script.  The clevis tool added TPM2 support early 2018 and made it out of the RHEL "beta" repo when RHEL 7.6 was released. I only got the automatic decryption to work on the full /dev/sd* volume, not any logical volumes.  I found this link very helpful:  https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/

I believe PCR0 is supposed to change if the BIOS firmware is modified and PCR1 changes even if certain settings are modified. I don't know the best PCR(s) to pick; my information is from a single system and the PC Client specification defining PCR usage  at https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf (Section 2.3.4, Table 1).


How does Shodan take screenshots from webcams which have authentication?

Shodan doesn't authenticate with the device at all so most likely the device added authentication after it was already crawled/ indexed. The screenshot in Shodan isn't real-time. It was taken when the crawler visited the IP. You can use our new website to see the timestamp of when the data was collected (top right corner of the banner). And you can click the "History" tab to see how long that webcam has been online.


Is it possible to encrypt portions of a file for upload so that one does not need to encrypt the entire file first?

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

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

  scp myfile.txt remotehost:

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

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

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

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

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

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

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

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

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

² For normal files, not taking metadata into account

³ Or any other arbitrary chunk size

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

The following script would just do that:

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

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

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


This is actually a really good question, and my answer is I am not 100% sure ... so I will tell you what I know and what I suspect and how to test it.

First off, if you are using WSS your server end is good to go.  Using WSS over WS is effectively the same as using HTTPS over HTTP.

Now the tricky part ... If you have clients A & B both connecting to server C with WSS ... and then you use STUN & TURNS, I would suspect that A would connect to B with the same WSS connection that each of them was previously using for connection with server C.  Key Word being SUSPECT

Since I dont have a https enabled STUN & TURNS server readily available to me for test, I personally can not test it and tell you everything is fine.  However, if you put wireshark on clients A & B you should be able to monitor the traffic between them ... and if it is not coming across the line using clear text ... then yes, the encryption holds.


What are the tools/frameworks/techniques for authorizing a device accessing a web app?

DO NOT USE IP ADDRESSES FOR AUTHENTICATION

Once that's off the table, what you describe is a "remember me" function for a web application. This has been discussed frequently here.

(and product recommendations are off-topic)


On urlscan.io Indicators of Compromise, what do the hashes represent?

This site uses an unusual understanding of the term IOC (Indicators of compromise). Essentially it just lists all resources it has found on the site, no matter if these actually indicate a compromise or not. Just try some known innocent sites like example.com and you still find  "IOC" reported.


Docker: Not able to read local file system

I'd start by saying you're making things a bit tough for yourself by doing this with curl rather than the docker CLI (it's a good thing to learn though)
So I think your problem here is that you've cat'd /etc/passwd inside the container, rather than /host/etc/passwd remember you're mounting the host filesystem with /host as a base, so you need to prepend that path to any files you're looking to get access to.


CGI-BIN - suspicious activity (unknown IP made request)

IP / port scanning is something that is happening on a daily basis. The cgi-bin directory is a standard directory and included in almost if not all wordlists used by directory brute forcing tools such as dirb, dirsearch etc. The cgi-bin directory is also of interest in relation to a know vulnerability ShellShock (read further to see whether your system is vulnerable or not). In regards to the script name, I believe it can be enumerated easily with already mentioned tools. If you care, you could employ firewall rules to restrict who, from where can access it (think of IP based restrictions, or perhaps use a custom User Agent and reject other connections). None of this are bulletproof but can help.


How can I misuse the information of DCE service enumeration?

Check this out. An attacker can see what services are running on the machine. This information can be very useful for planning and launching an attack.


Lets say a few months from now your company has reason to believe that there is a malicious actor in the network that occurred through leveraging servers in cluster A. However, the actor has been in the network for a while and has established persistence in many areas. Unfortunately, you decommissioned cluster A last month and all the data is gone. Now there are no logs to see what the actor gained access to, how they got in, and where all they went from there. If only you had done a quick look over the system and saved the logs you could have figured out what other systems are compromised!

In other scenarios, based on the content of the VM servers, you may elect that the disk space needs to be zeroed to ensure that data is unrecoverable. Maybe there is an ongoing testing engagement or forensics investigation involving that server that is unknown to other teams that are ready to delete it.

There are various reasons a particular security team may want to review this process and companies may have more specific use cases but that is the general idea.


Are UEFI motherboards software flashable? If so, is there any way to prevent it?

Well, that's one reason why UEFI sucks. In theory (and don't get me wrong: nobody serious in sec. ever believed this would work in RL) secure boot and signed drivers should prevent "malware" from being installed. But well: certs get stolen and exploits get found. There have already been many papers on that topic. This driver signing BS is more like a salesman argument from UEFI vendors in case anyone asks (as you just did). Story goes like this: Salesman: "yes we're aware of the risks and we're doing some magic that prevents that. Now I'm not an tech guy but our experts say it works. 100%.". Silence. Everybody in the management board nods in approval, IT-sec guy jumps out of the window.

Now while I'm bashing UEFI let's not forget that long before UEFI there have been (many) vendors that enabled you to flash your BIOS from within the OS (very common in the server / enterprise market but I've seen it on high-end enduser mainboard (ASUS WS PRO series) as well). They did that building proprietary chips  and interfaces. So this is not a entirely new problem with UEFI and one could argue UEFI made it better because atleast now we have a standard way to fuc* things up. One could also argue that now you don't have to reverse engineer ALL the mainboards because everyone is using the same known vulnerabilities. One could also say that UEFI made it worse due to unnecessary complexity, adding features to a bootloader nobody ever asked for, which increases the chance of bugs in the implementation.

That said please note that there are efforts to do things better. But unfortunately I yet have not had time to dig in deep into what those alternatives do better (maybe someone wiser can elaborate on this topic?) and - as so often in the history of technology - even if those approaches would be better than what UEFI has to offer they will probably always life in the shadow of the crap the industry has choosen (UEFI). So, till the first nuclear power plant explodes and people die I guess we'll have to live with UEFI (and even then I'm not sure something would change when it comes to IT security).

Oh and because you asked: no, there is nothing you can do to prevent malware from doing such an attack. Besides installing something else then UEFI (with potentially other risks and vulnerabilities). I'm not sure about possible "hardware modifications" that would prevent write access to the UEFI env. but if there is a way it'll probably be very hardware specific and probably not easy to DIY.

But let me tell you: if you panic by knowing this now better don't have a look at what Intel did with AMT (hint: AMD has similar BS). And no: you can't turn off that crap either.


Inconsistency Among MD5, SHA1, and SHA256 Hashing Protocols

A5E90C16BEB53BB93468496EAF2E0AC4 is the MD5 hash of that text with Unix-style line endings (LF).

8F18B10192372D8523558CF65DB2B1B2 is the MD5 hash of that text with Windows-style line endings (CRLF).

Since you're using Notepad on Windows, I'm guessing the first site is converting the line endings to Unix-style before hashing the text.


A common attack is to check hashes against common passwords. In that case your solution would add only one more round of decryption:

choose a common password (for example "password123")
decrypt the salt with the chosen password
hash the chosen password with the decrypted salt

Therefore you're only making attacks slower and introduce more complexity to your solution. I would use a higher cost parameter for your hashing algorithm.


What this type of attack called? (gaining peripheral information)

What you describe isn't technically an attack. Nothing is exposed, nothing is exploited, and the parties involved are not affected.

What you are describing is a phase of an attack called "Information gathering". Any targeted attack will involve Info Gathering at some point so that the attacker knows what to do to gain what is desired (DoS, access, data, etc.)


There are multiple things that can cause register spillage, from thread preemption as you mentioned to all kinds of interrupts. There is currently no way to prevent this, short of completely disabling interrupts (which is difficult when you take into account NMIs and SMIs) and preemption. This can only be done in kernelmode, and makes a computer completely unusable.

I think the issue is that you misunderstand the purpose of mlock(). It is not designed to keep sensitive information out of RAM (after all, locked memory is still memory), but to prevent it from being swapped to disk, either for security or performance reasons. Registers that have been pushed to the stack during a context switch are not subject to being swapped out in the first place. As soon as the context switch is over, the registers are restored.

  Does the kernel save registers in the same location each time?

The registers are saved to a few locations, depending on the origin of the context switch. In the kernel source file arch/x86/entry/entry_64.S, general purpose registers are pushed to the stack, usually using dedicated macros. They are later restored using pop. The relevant macros (such as SAVE_C_REGS and RESTORE_C_REGS) are defined in arch/x86/entry/calling.h.


These automated checks work by putting a script tag containing a random token into every field. For example, /someRequest?foo=x&bar=y might become:

GET /someRequest?foo=<script>alert("147230578")</script>&bar=<script>alert("561972456")</script>

It maintains a map of fields and the random values it chose (in this case foo=147230578, bar=561972456) in order to trace which parameter is injectable.

It then checks to see if <script>alert("147230578")</script> or <script>alert("561972456")</script> appear in the page without encoding. If the string is found, it knows XSS is very likely possible. If not, it either didn't appear in the page at all or it got HTML encoded.

In your case, it found that if it did get those strings reflected back, and identified which field was injectable. The reason it didn't execute is that the script tag got injected into a HTML attribute.

So, looking at your injection:

<input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>">

What happens here is the HTML is malformed, so the browser's renderer just tries to make the best of it, ignores both tags, and closes everything after the </script>. It then sees "> which it assumes is content and renders it on the page.

If we instead inject "><script>alert(1)</script> into the parameter, we get this:

<input type="text" name="cn" size="20" maxlength="20" value=""><script>alert(1)</script>">

This time the input tag is closed, which causes the script tag to get executed. Successful XSS! Again, the "> at the end just gets treated as content.

For a bonus round, what might we do if the vulnerable parameter doesn't allow the use of triangle brackets? Since we're already in an  attribute, we can manipulate the input element we're injecting into in order to execute script:

" onmouseenter="alert(1)" x="

This creates the following output:

<input type="text" name="cn" size="20" maxlength="20" value="" onmouseenter="alert(1)" x="">

Note that the x attribute doesn't do anything, it's just there to let us maintain valid HTML; unknown attributes are just ignored.

In this case, when the user's mouse enters the input element, it executes the JavaScript and we get XSS again.

But requiring user interaction sucks! We could use onload but this is often finnicky. Instead we can utilise some CSS tricks to force the user interaction:

" onmouseenter="alert(1)" style="display:block;position:absolute;top:0;left:0;width:50000px;height:50000px;z-index:999999;

This then becomes:

<input type="text" name="cn" size="20" maxlength="20" value="" onmouseenter="alert(1)" style="display:block;position:absolute;top:0;left:0;width:50000px;height:50000px;z-index:999999;">

The style here looks like a mouthful but it's quite simple:

Make the element display as a block element (so we can size it arbitrarily)
Make the element's position absolute within the window (so we can set its position to anywhere)
Move the element to (0,0)
Make the element completely fill the page (so the user's mouse has to enter it!)
Make the element appear on top of everything else.

Hopefully this explains how this all works and how you can go from the example given by ZAP to a working XSS exploit.


Realistic for organizations to avoid links in emails pointing to less known sites?

It is far more nuanced than you have described. And you need to provide more clarity for people on what "less known" means.
The feasibility of this process will depend on the company and industry. In some regulated industries, places have Allowlists on their firewalls and email filters to only allow links from the Alexa Top X plus known partners. Or just known partners. In other places, such a process would simply not work.
I regularly advocate for firewalls/filters to block "new" sites, where the domain is less than a month old. This is one form of defining "less known" domains.
So, whether your suggestion makes sense depends on the risk profile of the organisation and the impact of doing what you suggest versus the impact of something going wrong if they don't. Just offering vague blanket advice to all parties equally is where you are going to have trouble.
Define the risks and tailor the risk response to the organisation. Ultimately, that's what is going to be feasible.


Is Amazon's app store vulnerable to external storage race condition?

Amazon Store app actually controls the download and installation process, so it doesn't expose exactly this vulnerability. Note that the Google Play Store does essentially the same. Protection of the temporary disk space where the APK is being downloaded, may be compromized by a hacker; but at least both stores don't rely on the end user to manually install the file. Samsung devices have access to Galaxy apps, but this is again controlled by a preinstalled system app.

This is a limitation to Fortnite's model: no app on Play Store may become an alternative installer of APKs. Therefore, at some point, to achieve independent installation, you must use the unsecure manual installation of a downloaded APK.


Is there any security benefit to using physical machines over VMs?

It really depends on what is on the scope of "security".

If service availability is part of security, then usually, virtualized system are better on this topic because of:

the inherent mitigation of hardware fault.
Ability to take snapshot, etc... to ease backups and rollback

If availability isn't on scope, then i would tell that, for sure, physical server are more secure since you remove a whole layer (the hypervisor one) that could bring breaches or vulnerability.


How to practically detect current system net traffic?

You can't. Once your machine is infected with a rootkit / bootkit, it's no longer your computer. The malware has control of all system calls, so you have no way of identifying spoofed results. At best you can use an external device to identify what traffic is going in/out of the box.

If you're lucky, something like tcpview will trace particular TCP sockets back to a process, but you cannot possibly know whether a rootkit is spoofing such traces.


Is using a sqlite with random name file secure?

SQLite is not like a traditional DBMS in that it does not serve the content of the database to a computer network. It is actually kinda like just storing everything in a file. SQLite is will then allow your application to load that file and query it.

As such there is no need or advantage to a user account system as only programs on the same computer can interact with it anyway. The OS's file permission system should provide protection against not authorized reading/writing. Of course the machine on which this system is located needs to be secured as anyone with appropriate access on this machine can read/edit the database.

If you for example want to be able to only read table A but read and write table B then you should use 2 database files, one with only read permissions and the other with read/write permissions. How you do this is OS dependent.


DES-CBC3-SHA is affected by BEAST, but it might still be a better choice than RC4-MD5, because BEAST is considered mostly fixed on the client side while it gets easier every day to crack RC4.
See also https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat.
The best is of course to move to TLS1.1 or higher, but not all clients can do this.


Red Hat regularly puts its OS through FIPS 140-2 certification. See this press release from 2016.

Whether it works out of the box with zero config, I'm not sure, but that config should be easy to automate.

Also, be careful with the term "fips mode". Typically this means that, while running in this mode, the software only uses FIPS-approved crypto algorithms, and performs FIPS-style power-on self-checks, but simply turning on this setting does not mean that you meet all aspects of FIPS compliance. Unfortunately, unless you're buying a packaged hardware appliance like an HSM, there's no way around needing to read the manufacturer documentation to see what steps you need to do to be FIPS compliant.


How did an attacker spoof (or add to) this myspace's login form?

According to the article a user created a user named "login_home_index_html" then they used HTML and CSS to hide stuff on their profile page and make it look like it was the legitimate login page.  From what it looks like is MySpace didn't sanitize its user's custom HTML properly.


The TLS protocol itself has nothing to do with your browser and/or registry.  It is a documented standard that can be implemented by anybody.  What you're looking at are some registry keys to enable or disable various protocol versions for applications using SChannel, the TLS implementation in Windows.   As Yorick mentioned in a comment, SChannel implements the various TLS protocol versions, but they're not all enabled by default.   Originally TLS v1.2 wasn't enabled for compatibility purposes due to the number of sites that suffered from version intolerance bugs, (it is enabled by default now) and in the past SSL v2 and SSK v3 were enabled by default because there were many servers that didn't support anything better.  (And these are now disabled by default.)

Incidentally, you generally don't need to get into the registry editor to change these values.  There's available on the "Advanced" tab of the "Internet Options" dialog in Internet Explorer.


Should I consider naming my AMQP queues randomly?

Security is not an universal thing that can just be "improved", just like code can't be "optimized" just like that. You can only optimize code to do something better (e.g. improve execution speed at possibly the cost of readability), just like you can improve security by protecting yourself against something.

So when you want to give your queues random names, what do you think it protects against? Not really anything, except that it makes debugging harder.

If your communication is in plaintext for the attacker to see, then a queue named ngGyUnGLyDNgRAadYnGMyCNgSGNgtaLaHy will seem more "cryptic" than a queue named send-email, but by observing the traffic, and attacker will be rather quick at determining what a specific queue does.

Could this be considered "improved" security? Not really. It only marginally inconveniences the attacker, while at the same time it annoys your developers. Imagine getting an error report involving a queue named ngGyUnGLyDNgRAadYnGMyCNgSGNgtaLaHy. Now the developer in question has to either look up which queue that was, or remember several cryptic names - either option is annoying.

In Summary: Don't rely on security by obscurity. Enable TLS and test your configuration, ensuring that it is configured correctly.


Android: Internal memory safe in case of loosing the phone?

Reading unencrypted internal flash IC is a job that can be done for under $100. Last time I have checked, universal flash programmers were sold on e-bay for $30 to $300. If anything leads the thief to believe that your data is more valuable than your phone, this will be done.

If the thief is after your phone, they will have little incentive looking at your data. They will try to either unlock or reflash your phone to make it usable, whichever is easier. This may not be possible via external interfaces, but certanly doable if someone is willing to open the device: after all, those phones are flashed at the production line, so there is a way to do it.

Bottom line, you have to use encryption if you need to keep your data private. If that data is also valuable, you should use a more secure authentication method than a fingerprint.


Sample challenge questions for use with self service password reset and validation

Try the following: goodsecurityquestions.com - it provides a list of good and bad examples, along with guidelines on how to think about security questions. They also state that their guidelines have been used by Prudential, Delta Airlines, American Express and ING Direct.

Interesting quote from the site:

  However, there really are NO GOOD security questions; only fair or bad
  questions. "Good" gives the impression that these questions are
  acceptable and protect the user. The reality is, security questions
  present an opportunity for breach and even the best security questions
  are not good enough to screen out all attacks. There is a trade-off;
  self-service vs. security risks.


What can I do with crossdomain.xml access to a website

Let's call them vulnerable.com and malicious.com instead, with vulnerable.com hosting a crossdomain.xml file which allows access by malicious.com.

When a victim visits malicious.com (e.g. after clicking on a phishing email), a Flash page hosted on malicious.com could instruct the victim's Adobe Flash plugin to send any request to vulnerable.com reading the corresponding responses. Here you can find an example of how to exploit it.

If at the time of the attack the victim is logged into vulnerable.com, then malicious.com will be able to act on her behalf on vulnerable.com, for example to read or change registration details bypassing CSRF defences.

Even if the victim is not logged in some attacks are possible, for example posting anonymous comments, logging in the victim as another user to perform abusive activities, attempt a DDoS by sending requests from many clients etc.


Does allowing Facebook cookies over TOR threaten my anonymity?

If you've always used that Facebook account through Tor, and never through your normal connection, and the Facebook account is for an anonymous identity rather than your real identity and you never make any references using your real identity to your alter ego and vice versa, and you never login, then using Facebook over Tor does not necessarily compromise your privacy or security. The point of TAILS and Tor is that they allow you to partition your life into multiple identities in ways that someone knowing one identity won't be able to trace your other identities.

If someone wanted to trace you through your Facebook identity, they theoretically would be able to link your Facebook activities with any other things that you accessed through the Tor sessions that you used that Facebook account on. If you never use the same Tor session for anything that could've been linked to your real identity, then it's very unlikely that anyone would be able to link it to your real identity.

If you're using Facebook through Tor though, you should use Facebook's Hidden Service: https://facebookcorewwwi.onion


Find rogue access point if area is saturated with networks

That is not easy to know... it is supossed that you know the ESSIDs and BSSIDs of your own business. You can check the entire list in first place to see if everything is matching. The procedure from this base could be the following:

How to know if there is some rogue AP?

If you have your list updated you'll know about any strange MAC on your ESSID. In the case the Rogue AP cloned one of your MAC addresses, you'll see one of your BSSIDs duplicated and that is a very suspicious thing that only can mean there is a rogue AP independently of where it comes.

How to know where is the rogue AP coming?

Once located the data of the Rogue AP, the only method to know where is it, is to measure the signal strength and moving around you'll see if the signal is increasing or decreasing. AFAIK there is no other method.

Conclusion

I know if there are more than 60 networks, the scan list is an absolute chaos and is not an easy task. That's the reason about is important to audit regularly your wireless network to make the inventary of the legitimate Access Points. This is precisely one of the points on the known PCI Compliance. It forces to a company which is handling credit card and banking data to perform this auditory every 3 months. Anyway in my opinion is a good practice to perform this on any company even if is not handling banking data.


Frankly, I find such limits quite silly; any claim that a minimum length on the username has any security merit is ridiculous. Usernames are supposed to be public, they're not secret information (in the vast majority of cases). This is even more silly in systems where the usernames are used as communication handles and you're encouraged to share yours.

Some service providers believe that longer usernames are better to combat spam targeting auto-generated email addresses. Here's Google's take on this one

  We've discovered that short usernames at popular domains receive
  significantly more spam since they're easy to automatically generate.
  Gmail's requirement that all usernames be at least six characters in
  length is meant to keep spam out of your inbox.


Is there any good open source software for Security Risk Analysis?

No.  Security risk analysis requires intelligence, understanding of security concepts, knowledge of the application domain, and experience with security.  It's not something you can automate with a tool.  There is no substitute for having an experienced security expert understand your application domain and perform a security risk analysis.

(Of course, there may be opportunities for a security expert to use tools to help him/her with the analysis.  But the tool is not a replacement for a human expert.  A tool cannot perform a security risk analysis on its own.)


Hiding user account names from unauthenticated RDP sessions

When you say "Welcome" screen with all users listed. Is that so, or is it one named user and then  "Other user"?

If it is one named user and "Other user" then the named user is actually coming from the RDP client and is not being exposed. Depending on which client you are connecting with, but at least the Win XP client will save last connected user on the client side (even if the Allow me to save credentials is not ticked). My current Win 7 and Win 2008 RDP clients will authenticate before connecting (so you never see the login screen at all).

If my observation fits, you can prove it by entering a non-account on the client side without password, and it will still be displayed.


Is OSX vulnerable / susceptible to Gameover Zeus

No. The Zeus family of malware does not infect OSX, only Windows. Macs can of course be infected with malware, anyone who says otherwise is sorely mistaken. Some more info, GameoverZeus is simply an improved Zeus. It is run as a P2P (peer to peer) network, and operated by an HTTP control panel. The source code of Zeus can be found with a Google search so that's how that happened. It's one of, if not the most sophisticated bots on the market next to TDL. It's even able to bypass two factor authentication, along with all of the plugins you would see in bots like SpyEye, ICE9, Carberp, and Citadel.


How much can I learn about a nearby mobile phone with RX only and no decryption?

You can't get much with passive scanning. These days all the mobile phones (even low end ones) are on the digital systems (LTE, etc.) with most information being encrypted, once the initial handshake signalling is completed.

Even if you listen to the initial handshake, you won't be seeing any important phone identities being exchanged over the air in plaintext. For example, even in the days of 2G, with GSM, the IMSI would be replaced with TMSI (Temporary Mobile Subscriber Identity) for such handshake signalling, to foil RX-only passive snooping attempts.

Taking a step back, if it's a matter of differentiating between mobile phone (or cellular base station) transmission and other wireless transmissions, the frequency/wavelength of the transmission could be useful. Mobile phone systems used licensed bands (that often cost the mobile operators a lot of money), so you shouldn't be hearing traffic from other wireless systems in those bands. Googling around could probably get you more info on who is the operator in that area (there may be more than one, though), and even what frequency band(s) they have licensed for their mobile service. The cellular base stations typically would be broadcasting beacons so that mobile phones can select a suitable base station to connect to and initiate the handshake/setup, including synchronizing for the timing of the frames, etc. This is known as the access or random access procedure. More details can be found in https://www.eventhelix.com/lte/random-access-procedure/lte-random-access-procedure.pdf for instance.


Spoofed IPv4 and IPv6 addresses over the internet

1) There doesn't appear to be a usual policy. Many ISP's do now drop packets with spoofed addresses, but there are still loads that do not.

2) When NAT'ing, a correctly configured router will have a small list of rules which define the IP address which will be attached, so the usual attack is to send from a location where this doesn't happen.

3) One of the reasons for NAT'ing is to allow you to have multiple IP addresses behind the ones you own on the Internet. With IPv6 this may be far less of an issue, so NAT'ing may end up being used less or not at all. You might think this may change the way protection against spoofed addresses would be implemented but it shouldn't - you will still implement rules which say for a router with a network A on one side, any packet with a source address that matches A coming in a different interface should be dropped as a spoof.


HTTP/HTTPS/GET/POST : in which cases can a malicious router between client and server find a secret information?

As long as the traffic is not protected (i.e. only plain HTTP is used and not HTTPS) a device in the path of the connection (like a malicious router) could in theory read and also modify the data without notice. This includes URL, URL parameter, POST body etc. Of course, the actual capabilities of the devices vary.

If the traffic is protected with HTTPS the body of the request and also the request header including path and URL parameters are protected against sniffing. Domain is part of the TLS handshake but is at least protected against modification too.


How does Google locate me from my laptop?

There are a lots or ways to find a user's location, independent to the OS or device manufacturer.

Google is known to do wardriving, which maps GPS position
to router location (BSSID).
With your public IP, there are IP Location databases/service (NOT
BSSID) like:
ip2location.com, iplocation.net, MaxMind,
ipaddressservices.io ...
You don't actually need to do it, some else might update your BSSID
when it finds it on his phone and it does not even have to be an
Android device, Apple does this too and you know, how's the
business, it wouldn't surprise me that they exchange/sell info.


Uploading Disabled for executable file during change of Extension

You can not block the upload of executable files. That's it, there's no way around it. However, you can change the way you think of uploaded files.

First thing you need to do is to know where your users upload files, and then lock down that directory. If you're using Apache, you can prevent it from asking to execute files in a certain directory by adding the following to your http.conf.

<Directory "/var/www/my-upload-dir">
  AllowOverride None
  Options -ExecCGI
</Directory>

Other things you can do include using random names for the files once uploaded, only serving the files via a proxy script and storing the files above your document root.

Finally, a very important thing is to never include, use or import any user-uploaded file.


Should we configure all devices to never request SSL 2.0, and reject it if offered?

Regarding industry accepted practices:

(from http://www.rapid7.com/vulndb/lookup/sslv2-and-up-enabled)

  "SSLv2 has been deprecated and is no longer recommended. Note that neither SSLv2 nor SSLv3 meet the U.S. FIPS 140-2 standard, which governs cryptographic modules for use in federal information systems. Only the newer TLS (Transport Layer Security) protocol meets FIPS 140-2 requirements. In addition, the presence of an SSLv2-only service on a host is deemed a failure by the PCI (Payment Card Industry) Data Security Standard.
  Note that this vulnerability will be reported when the remote server supports SSLv2 regardless of whether TLS or SSLv3 are also supported."


How do I discern the authenticity of the website?

It doesn't seem like you are asking how to determine if a site is posing as the 'real' site, which would be phishing, but what you are really asking is how to validate the content of a site, which is more of a philosophical question than a technical one. How does one determine, for instance, that The Onion is not a real news site?

We can check the 'whois' information for the domain to see if it makes sense, but even then, there might not be enough data to go on. SSL certs might help to provide extra data, if one is used and not faked.

We can use Google searches to search for likely 'true' sites and compare, but that has its own obvious limitations.

How, then, can you determine that an otherwise legitimate site is offering valid and true information? You need to validate. Just ask wikipedia. They hope that with enough eyes and hands, the truth should bubble to the surface, but that is only marginally effective.

This goes back to the very first advice handed out when websites started to become popular: use your head and don't believe everything you hear.


Is it safe returning or giving away a sim card you already used?

This begs one and only one question:

Did you manually store any data on the SIM card?

No? Then yes, it's perfectly fine to return.

Older devices, like feature phones, that didn't have a lot of built in storage or had incredibly slow storage would store text messages or phone numbers on the sim card to save what little space they had and keep your things easily transferable. Eventually they realized how dumb of an idea this was and stopped doing it. So unless you have forcibly saved contacts to your sim, or text messages, or your phone is dirt old, then there is very little to no data on the sim card other than what was already on there.


Would using distinct IP addresses help support browsers with older SSL implementations?

Your particulars are wrong (it is not a problem of encryption per se) but you have the right general idea.

In SSL/TLS, the client first connect to the server and sends a "ClientHello" message stating "I wish to do some SSL with you". This happens just above the TCP layer, and below anything which is related to HTTP; an HTTP request will be sent within the SSL tunnel only after the SSL tunnel has been created. SSL tunnel creation is done through the procedure called "the handshake", of which the ClientHello message is the first step.

During the handshake, the server sends his certificate to the client. The certificate contains the server name and his public key, and it is signed by a certification authority. The client will accept to use the public key only after having "validated" the certificate, a process which entails the two following steps:

The client must verify the signature by the certification authority over the certificate. It may have to validate the certification authority's own certificate before that, though; the process is recursive. Certificate validation is full of intricate details which I will skip here because they are not relevant to this discussion.
The client must check that the intended server name indeed appears in the certificate. Because that's the point of the certificate: to bind a public key (a mathematical object with which cryptography is done) to an identity (the server name); the certification authority issues the certificate (i.e. signs it) only after verified in some way that the public key is indeed the one for which the server controls the corresponding private key.

Once the client is reasonably sure that he has the correct public key, he can finish the handshake: depending on the negotiated cipher suite, this entails asymmetric encryption or digital signatures; either way, the server will use his private key. At the end of the handshake, both client and server end up with a shared session key with which more cryptography is going to happen, this time symmetric encryption.

Then, and only then, can "application data" be transfered through the tunnel. In the case of HTTPS, "application data" contains the actual HTTP request.

Now, the problem is the following: the client wants to contact a given server (with a name such as www.foo.com), but that intended server name is sent to the server only with the HTTP request. At the TCP level, only IP addresses exist. When the server needs to send his certificate, he only knows that it was contacted under some IP address, but it does not know under what name the client tries to locate it. Nevertheless, the server must send a certificate which contains the right name. When the server only hosts a single HTTPS server per public IP, that's easy: only one possible name. With several HTTPS servers sharing the same public IP, the server has to do some divination, which, on a general basis, is not possible for computers (it is already quite hard for augurs).

Possible solutions:

Embed several names in a certificate. The server has only one certificate, but it contains the names of all the HTTPS servers which share the public IP. This is supported in X.509 as the Subject Alt Names extension. This requires client browsers to actually support standards the way they should, so this is not a given. This page claims that most browsers support it, but I think this warrants at least some extensive testing (especially when there are several names in the extension and these names contain the "wildchar" *).
Enhance the protocol with an extra exchange at the beginning. This is known as the STARTTLS option. In an HTTP context, this means that the client would first sent a special HTTP request which contains the server name, with a special command (namely "STARTTLS" instead of a normal "GET") to indicate the willingness of the client to engage into an SSL/TLS handshake right away on the same connection. This has been proposed at some point for HTTP, but rejected because it does not work well with existing HTTP proxies. STARTTLS is used in other protocols such as SSMTP or IMAPS, where an actual connection is always available.
Have the client send the intended server name early enough in the handshake, e.g. by smuggling it somewhere in the ClientHello message. This is known as Server Name Indication. This is what the HTTPS world is aiming at.

The biggest issue with SNI is that it is not supported by IE on Windows XP (it requires IE 8+, but also a Vista or newer version; because the actual SSL code used by IE comes from the OS, not from IE itself). So you have to somehow induce your clients with WinXP to switch to Firefox, Chrome, or some other browser which knows about the SNI and does the SSL itself instead of relying on the implementation provided by the OS.


Simpler idea for protection against reflected XSS on client side

My question is- why don't we store what ever is going to server as parameters and if these parameters are reflected in HTML response then discard it or encoded it

Any parameters? So if I search for “Hello” and the response page contains the text “Here are your results for Hello”, it gets mangled?

There has to be some criterion for what counts as potentially dangerous, otherwise every form on the web is going to break like this. You could start out with “any parameter with a < in”, but then what about attribute injection attacks like onmouseover=, or JavaScript injection like '; alert(document.cookie)? And how do you stop a parameter of just < from breaking every tag on the page? There isn't an obvious watertight answer, which is why detection ends up being a complex mess of heuristic rules and not a clean, watertight pattern.

Personally I think client-side reflected-XSS detection is deeply misguided: in principle doomed to failure and in practice worse than useless, but if you're going to do it you'll need to limit its scope because content reflection is a common property the web needs to work properly, not always an attack.


Using same algorithm for signing and encrypting a message

Although the names of the algorithms are the same, they are actually a little different when used for signing vs when used for encryption. The only thing similarity the two algorithms have is that they both use the same trapdoor permutation, conveniently called RSA. The difference is both in where certain variables come from, and the use of padding, which turns the insecure function into a cryptographically secure and useful algorithm. Encryption often uses RSA-OAEP, whereas signing uses RSA-PSS.

So even if you are using RSA/RSA for encryption and signing, an attacker who intercepts the message will be able to neither decrypt it nor forge valid ciphertext without first obtaining the relevant private key.


Assuming I'm using Starbucks Wifi, is there a point of using a VPN if I want to remain anonymous?

Your scenario falls under one of the major use cases of a VPN, which is to protect yourself from untrustworthy public Wi-Fi hotspots. Other use cases being, overcoming geographic restrictions when it comes to streaming and accessing certain websites.
The most fundamental selling point of a VPN is to allow access to the public internet using a private connection.

somewhat anonymous since my IP address would be the same as other users connected to the same network?

'Somewhat' is right but having a different IP address does not mean that your identity & connection is secured. As you've mentioned that there are other users on the same network, that alone nullifies the anonymity that you are trying to achieve.
Anonymity should be the least of your worries, I'm more concerned about this from a security standpoint.


What are the implications of including binary blobs in the Linux kernel?

From a security, and even ideological, point of view; blobs are unacceptable.  whatever people say, they are trying to dissuade you from the importance of this issue.
the risks users of non-free software face, be it a firmware blob, driver blob, or Microsoft Windows, are vastly unmeasurable. and while it is safer using any Linux distro than Windows, it doesn't mean that any Linux distro is secure.
blobs, depending on their size, can do just about anything, they are little programs after all.
as for detecting backdoors and other security flaws, there is only one way, and it is quite simple; publish the source code. the previous answer points out that:
"A binary will be much faster than other code." Liar, Liar, Pants on Fire.  a blob will only make the final compiling process of the program faster, not the program itself,
but regardless of program performance decisions,  there's no reason not to publish the source, and compiling instructions of that "blob"
and anyone telling you otherwise is either lying, of some kind of NSA, FBI agent.

if you are interested in a 100% FOSS (free and open source) operating systems, that consciously maintain their code to be blob free, here is a link: Free GNU/Linux distributions  other relevant links: What is free software?, techrights.org/2013/11/25/freedo-and-nsa-code/.


What are best practices for implementing ACL

You need externalized authorization e.g. claims-based authorization (Microsoft-specific) or more broadly attribute-based access control (ABAC).

ABAC was recently defined by NIST and you can download their report here.

In your questions you point to LDAP and groups. You then explain you need to associate functions to groups / roles. LDAP, roles, and groups represent your attributes. They could also come from other sources (e.g. a database). What you're missing is the authorization logic: the mapping between groups and functions.

In ABAC, that logic is expressed as authorization policies. OASIS has a standard for that called XACML, the eXtensible Access Control Markup Language. In XACML, you'll use attributes to define which access is to be allowed or denied.

For instance:

  A user with the role manager and in the group finance can view the finance menu.

You can read more on XACML here and here.


Under HIPAA, is it allowable to remember/store user credentials?

The security rule of HIPAA doesn't specifically address this. However, if you can prove that touchID requires actual validation of whomever is authorized for the ePHI for access-- then it suffices. However, you could be dinged on the implementation configuration for system security safeguards so you'll need to have documentation and compensating controls if required for any weaknesses related to touchID and specifically how your mobile device is managed. You may also want to validate with the vendor if a risk assessment has been performed for other customers for HIPAA environments.


Is this enough to tackle script / malicious code insertion in GET, POST requests?

No. It's blacklist-based, it tries to take care of specific tricks involving html entities.  It doesn't even require magic_quotes, and magic_quotes has been deprecated as inadequate.  Chris Shiflett is just one of many who've written a blog post explaining how vulnerable that is; it won't even stop modern automated script-kiddie attacks.

Use prepared statements in the database, and you'll be most of the way there--although even prepared statements aren't foolproof.


Which attributes in the subject of a X.509 certificate from a certificate authority are used as the "identifier"?

The full subject of the issuer certificate should match the full issuer attribute of the issued certificate.

  I almost never find an exact match, especially with the Common Name "CN" attribute.

My guess is that you look at the issuer of the server certificate and then try to find the matching root CA. But usually there is an intermediate CA in between server certificate and root CA. This means the issuer of the server certificate is the intermediate CA and the issuer of the intermediate CA is the root CA.

In other words: The server certificate is not issued directly by the root CA. The issuer of the server certificate is therefore not the subject of the root CA. And you cannot find the root CA just by looking at the server certificates issuer.

Instead you have to explicitly take intermediate certificates into account. For example:

Server certificate of security.stackexchange.com:

subject: /C=US/ST=NY/L=New York/O=Stack Exchange, Inc./CN=*.stackexchange.com
issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA

Intermediate certificate - subject matches issuer of server certificate:

subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

Root CA - subject matches issuer of intermediate certificate:

subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

For more information see also SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?


Is it safe (or a good idea) to advertise the use of bcrypt?

The usual argument goes that way: if it is not safe to describe what algorithms you use, then you have a bigger problem. Therefore, you should be able to announce to the World that you use bcrypt with no ill effect on security. In fact we must assume that the attacker already knows that you use bcrypt (if he is in position to do harm, then he can probably see your code; also, bcrypt output from usual bcrypt implementations has a quite recognizable format).

Knowing whether it is a good idea, from a marketing point of view, to turn bcrypt usage into a sales pitch is another matter. Personally, I think that saying "we use HTTPS and all passwords are stored hashed with bcrypt" will do no harm over the simpler "we use HTTPS". I cannot claim that it would do good. Also, there is such a thing as going too technical, in that you might inadvertently show yourself as "a bunch of geeks" which may or may not appeal to your intended customer crowd. This all depends on the kind of image that you want to project, and the average psychological profile of expected site users.


How does Amazon bill me without the CVC / CVV / CVV2?

That code isn't necessary. This may cause more fraud and more chargebacks, but Amazon keeps those numbers low so that they can offer a faster shopping experience such as one-click.

The only thing necessary to make a purchase is the card number and, in all but rare cases, expiration date, whether in number form or magnetic. Most systems require more information (such as matching full name, bank phone number, physical billing address with zip code, et al) so that they can deal with fraud and/or chargebacks, and sometimes this is enforced by the issuing bank.


Your quote describes symmetric key strength, but your counter examples (1024, 2048 bits) reference keys used for asymmetric cryptography. The number of bits required for strength is different between the two.

Your quote is from section 7.1 of Applied Cryptography; if you move ahead to section 7.2, for example, you'll see Schneier's predictions on what lengths will be required to have secure asymmetric keys over time:

Printed in 1994, his predictions turned out reasonably sound except insofar as it is flatter across segments (e.g., individuals don't accept lesser key lengths).  (For non-historical purposes,  you should look for more up-to-date recommendations, such as NIST as summarized by KeyLength.com)


You did nothing wrong. The signature is correct, but GnuPG could not verify the key's validity, thus the signature is not deemed valid. With other words, GnuPG explains you that while the signature is issued by a totally valid key, the key could have issued by anybody (you can create keys for arbitrary mail addresses, there is no central instance verifying them, especially key servers do not do!).

Now you have two options:

you can try to validate the key through the web of trust (which means finding a "trust path" from keys you already trust to the author's key, and will also remove the "unverified" message) or
validate through some other means, for example by comparing the fingerprint or at least long key ID with another, trusted source (short key IDs are insecure, so don't use them for verifying keys). This basically means you have another, trusted source (a basic verification would be through the product's web site listing the key ID/fingerprint, given it is at least received through an encrypted connection using HTTPs) with GnuPG's output of the public key used for signing:

Primary key fingerprint: B35B F85B F194 89D0 4E28  C33C 2119 4EBB 1657 33EA

(the long key ID equals the last 16 characters 21194EBB165733EA, the short ID is the last 8 characters 165733EA).


What is the recommanded periodicity for antivirus RAM and disk scans?

I am not aware of antivirus programs scanning files when they are changed, but they don't really have to. As long as they are scanned before they are loaded/executed and the program modifying them is scanned, it should be fine.

There are many reasons to scan RAM for viruses. I can think of two major ways viruses may appear in RAM even though the files were scanned. One is for the virus to be encrypted. The antivirus would not be able to identify it, unit it was decrypted in memory. The other is by network attack, for example abusing a buffer overflow to write the virus directly to memory without storing it in a file. However, many antivirus programs will have ways to deal with both of these scenarios to some degree. Obviously this means ideally you would want to scan your memory as often as possible and you need to balance it with your performance requirements.

The reason why full disk scan is justified is that antivirus signature databases are being updated regularly (possibly every day). A virus may not have been known and detectable when the file was downloaded but may be detectable now. However, because files are scanned on load, this only makes sure there are no latent viruses on the disk. I would say once a week should be enough for this.


How symmetric-key length affects TLS if the server's PK is strong

The main weakness of DES is its short key length. This makes DES quite easy to brute force. An attacker would record the whole HTTPS session and then try each key until he has found the right one that can decode the conversation.

There are other attacks on DES which allow breaking it faster than brute force, but these need quite a lot of known or chosen plaintexts. This would not be feasible in your scenario.


How secure is opening an incoming port for a java application?

I think you're making some incorrect assumptions about Java - Java itself does not listen on a port.  Applications RUNNING in Java do.

So Java itself, running on your PC/server isn't listening for anything.  If you're, say, running a Minecraft server, which runs in Java, then traffic to/from that Minecraft server hits both Java and the app.  If the app has a vulnerability, you can be compromised.  If Java itself has a vulnerability, you can be compromised by virtue of the fact that the JVM sits between network traffic and the app.  I am unaware of any such exploit at this time that directly targets Java via network traffic alone (i.e. a specially crafted packet that depends on the packet only rather than a vulnerability in the Java app) - most vulnerabilities are in the ways apps interact with Java.  That's not to say one does not exist - I am just unaware.

With regards to:

  Regardless of how many times I change my dynamic IP, I'm getting port scans, attempts to connect to certain services such as ssh, and other phenomena.

That's a fact of life on the internet.  EVERY public IP address is CONSTANTLY scanned for SSH, open ports, etc.  This isn't a function of your ISP or your server - it's a function of the internet as a whole.  That's why it's so crucial to have adequate firewalling in place.  You're not any more targeted than any other random IP address out there.


Checking a key is signed

The short answer is that you use the command gpg --list-sig <key id>.

For example, I went to the site you listed above and downloaded the qubes release 2 signing key. I then imported that key into my local gpg keyring:

$ gpg --import qubes-release-2-signing-key.asc

which results in the following

pub   rsa4096/0A40E458 2012-11-15 [SC]
uid   [ unknown] Qubes OS Release 2 Signing Key

To check if the key has been signed, you can use the command gpg --list-sig <key id>.

In this case, we can see that the key ID is 0A40E458 from the output above:

$ gpg --list-sig 0A40E458
pub   rsa4096/0A40E458 2012-11-15 [SC]
uid         [ unknown] Qubes OS Release 2 Signing Key
sig 3        0A40E458 2012-11-15  Qubes OS Release 2 Signing Key
sig          36879494 2012-11-15  [User ID not found]

The last entry is the Qubes master key, but it is unknown as I don't have it on my keyring. If I then download the master key, and add it to the keyring:

$ gpg2 --import ./qubes-master-signing-key.asc
gpg: key 36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1

I can verify again and see that the release key is correctly signed:

$ gpg2 --list-sig 0A40E458
pub   rsa4096/0A40E458 2012-11-15 [SC]
uid         [ unknown] Qubes OS Release 2 Signing Key
sig 3        0A40E458 2012-11-15  Qubes OS Release 2 Signing Key
sig          36879494 2012-11-15  Qubes Master Signing Key

Verifying signatures

When a file is signed using a gpg key, a separate signature file is created. With the qubes example, they release a .DIGESTS file. See the heading 'Verifying Digests' in the link you provided for more details on how to check such a digest.

Basically, what they have done is taken the file that is purported to come from them, and run a variety of hash algorithms against it. A hash function will take an input file or message, and output a unique fairly short hash string. This is cryptographically created in way that makes it very difficult or nearly impossible to find any other file that would produce the same output.

They then sign this hash string with their GPG key. Both the hash and the signature of that hash text are put inside the .DIGESTS file.

The important part to note with this process is that any change to the original file being verified will produce a completely different hash string. Therefore, when you run the verification command, what is happening on your local machine is that your system is creating it's own hash of the given file and checking that it matches the hash inside the signed text. If they both match, and the signature is verified as coming from the key you have already decided to trust, then you know that the owner of the key has 'signed' the version of the file that you have downloaded.


How secure is this schema between a Desktop App (c++) and an API (php)

Problem 0: You don't need to send the hash of the password, because you're already using TLS (HTTPS).  If you do send the hash, then the hash becomes the password.

Problem 1: Preventing users from generating a fake JWT response.

You're already using TLS.  Pin your server's certificate.  That is, include the server's public key in your app. If anything answers with a certificate that doesn't match the public key, then the app isn't connecting directly to your server.

Problem 2: Preventing replays of a valid JWT response.

Use a new nonce each time.  (Also, every few seconds? If their connection to the internet needs to be reset, and they don't need to access resources on a server to do work in your app, only to make sure that their session hasn't been revoked, then give them a few minutes.)

Problem 3: Keeping different computers uniquely identified.

You're using TLS, so they can't change the bytes on the network.  Simply produce a random nonce when the user logs in, identifying that session. Don't store it on disk, keep it in memory.  They would have to crack your app to change that, which you've already said is beyond the scope of this question.


Is there value in storing passwords in their own table with encrypted or hashed keys?

If you use an appropriate cryptographic password hashing function (e.g., bcrypt, scrypt, or PBKDF2), the value added by this approach is negligible. So, really, the solution is simply to responsibly hash your passwords in the first place.


From your description it seems that for your purposes, a persistent file in your app will be enough. You will get some 'false positives' when users wipe the app data, or uninstall your app and reinstall it later, but this should not be a big problem if it only results in a private mail notification, as for Google logins.


Is it possible to infect an e-mail by accident?

Before answering your questions, let me summarize "3 Top Ways People Get Infected by An Email Virus" by Tina Sieber. In general there were three common things related to email infection/the methods which the user might get infected, which might fall into infected email's prey under these circumstances:

A Virus As An  Hoax

First rule of thumb: never trust hoax emails and don't forward unless it's genuine,teach your friends regarding it, here is a good resource to get informed about email hoaxes and hopefully verify the credibility of an email you have received.
A Virus In An Email Attachment

The most common part of email viruses was spreading through attachment,

  Attachments that contain viruses are either executable programs (file types: .com, .exe, .vbs, .zip, .scr, .dll, .pif, .js) or macro viruses (file types: .doc, .dot, .xls, .xlt). The safest way to avoid them is to not open email attachments.

If you were using a secure email provider like gmail or zimbra it will alert you and ensure online scanner was present at the time of downloading, else never consider to open the file without scanning.

One of the common mistakes people do is editing rich text word file without scanning it, beware it might be injected with exploits.
A Virus In The Email Body

Malicious content can be found in the body of an email - beware it doesn't contain a vulnerable email body.
Will the infected victim transmit the virus through email?

The answer might vary based on operating system and the mail client the infected victim yes,there were more possibilities to get infected, Several email clients have built in scanners and avoid it but some of the more outdated scanners allow them to upload with malware.

As for your example; consider the shopping bill with injected malicious code, obviously a PDF can be injected with a malware - take a look at how they inject into it.

Second thing if a spam email is forwarded - here's is an article discussing how spam emails can infect you. Here's a quote from "Spam: Unsolicited email messages" by Panda Security:

  Spammers try to obtain as many valid email addresses as possible, i.e.
  actually used by users. They use different techniques for this, some
  of which are highly sophisticated:

Mail lists: the spammer looks in the mail list and notes down the addresses of the other members.
Purchasing user databases from individuals or companies: although this type of activity is illegal, it is actually carried out in

  practice and there is a black market.
      Use of robots (automatic programs) that scour the Internet looking for addresses in web pages, newsgroups, weblogs, etc.
      DHA (Directory Harvest Attack) techniques: the spammer generates email addresses belonging to a specific domain and sends messages to
  them. The domain mail server will respond with an error to those
  addresses that do not actually exist, so the spammer can discover
  which addresses generated are valid. The addresses can be compiled
  using a dictionary or through brute force, i.e. by trying all possible
  character combinations.

  Consequently, all email users are at risk from these types of attacks.
  Any address published on the Internet (used in forums, newsgroups or
  on any website) is more likely to be a spam victim.

  Techniques used.

  Spammers use numerous techniques to produce messages capable of
  by-passing all types of mail filters. Some of the tricks used to
  obscure the message’s HTML code are looked at below:

Division of message subject line using bogus line breaks:

Subject: =?utf-8?q?Identical drugs -- l?=
=?utf-8?q?ittle monetary valu?=
=?utf-8?q?e!?=
Use of null characters (Quoted-Printable type encoding):   =00H=00T=00M=00L=00>=00<=00H=00E=00A=00D=00>=00=0D=00=0A=00<=00M=00E=00=
        T=00A=00 =00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00=
        t=00e=00n=00t=00-=00T=00y=00p=00e=00 =00c=00o=00n=00t=00e=00n=00t=00=3D=
        =00"=00t=00e=00x=00t=00/=00h=00t=00m=00l=00;=00 =00c=00h=00a=00r=00s=00=
   =00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=0D=00=0A=00<=00M=00=
        E=00T=00A=00 =00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00=
        M=00L=00 =006=00.=000=000=00.=002=008=000=000=00.=001=004=000=000=00"=00=
        =00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00=
        /=00H=00E=00A=00D=00>=00=0D=00=0A=00<=00B=00O=00D=00Y=00>

  Interchanging letters in the words used. The message is still legible
  to the recipient, but the filters do not recognize the words used:

I finlaly was able to lsoe the wieght I have been sturggling to
lose for years! And I couldn't bileeve how simple it was! Amizang
pacth makes you shed the ponuds! It's Guanarteed to work or your
menoy back!
Inverting text using the Unicode right-to-left override, expressed as HTML entities (? y ?):

  Your Bnak Cdra Linknig

  (Your Bank Card Linking)
      Encapsulating a  tag with an HREF tag, so that a legitimate URL appears instead of a malicious one.

 <A HREF="<URL_LEGÍTIMA>">
    <map name="FPMap0">
    <area coords="0, 0, 623, 349" shape="rect" href="<URL_MALICIOSA>">
    </map>
    <img SRC="<img_url>" border="0" usemap="#FPMap0">

Use of ASCII characters to “design” the message content:

  Although some of the techniques used have now been mentioned, there
  are many more, such as the use of incorrect HTML tags, URL encoding,
  the use of HTML entities to conceal certain letters, the use of
  invisible ink, etc.

  Other types of techniques are based on including the spam message as
  an attached file in a valid message or the use of CSS (Cascading Style
  Sheets) in spam messages to conceal certain words or parts of the
  message.

  Methods used for spam distribution are as follows:

Vulnerable or poorly configured mail servers (Open Relay) which allow any user to send messages without checking their sender (which

  will normally be spoofed).
      Computers affected by malware: certain types of malware facilitate the sending of spam through affected computers, such as the
  installation of proxy. servers. It is even possible to rent botnets,
  real computer networks affected by bots (hybrids of worms, Trojans y
  backdoors).

So in summary:

Infected email can be transmitted by accident
Through shopping bills, documents the medium might vary, but beware there might be backdoor in it

How can I prevent it?

Never Underestimate any file, don't allow any email attachment to execute without scanning
Use email client with a virus scanner or with virus scanner integration with your existing solution
Keep scanners up to date
If possible educate your friends about dos and don'ts
Never trust offers, hoax unless it's official sources

The basic rule for attacker is to trick you and steal your stuff, don't give fall for it.


Flash drive returning odd files, and self creating others, any ideas?

If you actually did wipe the entire USB with random data, it's possible some of the sectors on it contained data which looked like the start of a FLV or other file type. File carving (the technique I believe you are describing) works really well on some file types, while others will generate many many false positives. The names are random since it has no filesystem to tell it what the name should be.


Host-based security architecture for web server network

I have recently implemented this solution and tested it using 3 VMs. The attacker uses Kali, the web server uses Ubuntu 14.04 and the honeypot actually uses HoneyDrive 3. I had to change it a little bit.

So basically what this architecture does is receive a packet, check it agains the firewall (iptables) rules and log it. Fwsnort converts Snort rules into iptables rules, making the firewall a kind of IPS. The log monitor (psad) then analyses the log, identify malicious IPs and block then. From this point on, every incoming packet from these IPs will be forwarded to the Honeypot.

Here are the main rules that do it:

###### forwarding ######
ipset create banned_nets hash:ip hashsize 4096

iptables -t nat -A PREROUTING -p tcp -m set --dport 8181 -j DNAT --to-destination $HONEYPOT_ADDR:443 --match-set banned_nets src
iptables -t nat -A POSTROUTING -p tcp -s $HONEYPOT_ADDR --dport 443 -j SNAT --to-source $SERVER_ADDR:8181

iptables -t nat -A PREROUTING -p tcp -m set -j DNAT --to-destination $HONEYPOT_ADDR --match-set banned_nets src
iptables -t nat -A PREROUTING -p udp -m set -j DNAT --to-destination $HONEYPOT_ADDR --match-set banned_nets src

iptables -t nat -A POSTROUTING -p tcp -m set -j SNAT --to-source $SERVER_ADDR --match-set banned_nets src
iptables -t nat -A POSTROUTING -p udp -m set -j SNAT --to-source $SERVER_ADDR --match-set banned_nets src

echo "[+] Activating IP forwarding"
echo 1 > /proc/sys/net/ipv4/ip_forward

I had to update the tricky part of forwarding blocked IPs. At first, psad would only drop packets incoming from blacklisted IPs. These IPs are listed in auto_blocked_iptables text file. So I wrote a script to get these IPs and insert them in an ipset. I called this the update_daemon With this feedback mechanism the firewall is able to forward packets by checking their origin with the ipset elements.

Here is how I did it:

#!/bin/bash
#ipset banned_nets must already exist

AUTO_BLOCKED_IPTABLES_PATH=/var/log/psad/auto_blocked_iptables

update_set(){
    ipset flush banned_nets

    grep -E -o '^([0-9]{1,3}[\.]){3}[0-9]{1,3}' $AUTO_BLOCKED_IPTABLES_PATH |      while read -r line ; do
         echo "Processing $line"
        ipset add banned_nets $line
    done
 }

while true #run indefinitely
do
     inotifywait -e modify $AUTO_BLOCKED_IPTABLES_PATH | update_set
done

The hole project is available at 2.

So answering my own questions:

Will this architecture be effective?
Yes, it does forwards pre identified attackers to a honeypot, then protecting the server.
Are honeypots a good idea?
Honeypots seem to be an interesting idea. With a honeypot we can better understand the attacker, his methods, main targets, exploits, wordlists and a lot more.
If so, should I run them on a VM?
According to 3, running honeypots in VMs does is a good idea. Since honeypots are supposed to be low interactive, they do not require too much hardware resource. On the other hand, the system gets vulnerable to vulnerabilities in the honeypot software and in the VM itself.
Can I guarantee QoS? Or will my server be overloaded?
I did not test sufficiently the system for QoS. Still it seems to me the forwarded traffic will increase data flow.
What else am I missing (about anything related)?
Forwarding is not so simple as it seems the server must act as a transparent proxy and the update_daemon was a tricky part, since it dynamically monitors a file.
Also, the solution does not shows good results when suffering DoS attacks. In this case the best option seems to be removing the honeypot and just dropping the attacker. This partial solution is also available at GitHub.

You will find more information at 2 and 4


Is there any risk involved allowing users to create their own URL's

It depends on the validation that is in place regarding the username.

If you already

whitelist the characters in the username to alphanumeric only
restrict the maximum size of the usernames
ensure username unicity
ensure that no username can match existing url's (depends on your site, maybe this is not needed.. It is if you have for example something like /default/shop or /welcome/shop)

, I don't see much of a risk :)


What happens when encrypting with private key?

For encryption, person 1 encrypts their message with person 2's public key, not with their own public key. Then only person 2 can decrypt it, since only person 2 has the matching private key.

Encryption with the private key is used to prove authenticity. If person 1 encrypts a message with their own private key then person 2 can decrypt it with person 1's public key, which proves that person 1 originated the message since it could only have been encrypted with their private key.

All of which assumes that you have a secure and verifiable way for persons 1 & 2 to exchange public keys, which is always the difficult bit.


For use with RC4 how do I combine a reused key and an initialization vector

how would I combine a reused key and a unique initialization vector in a secure way?

The standard method of combining the key and IV in RC4 to avoid vulnerabilities is to concatenate them and pass them through a cryptographic hash, and use that hash's digest as your RC4 key. This defeats the severe related key attacks that can allow recovery of the key by destroying the exploitable relations.

  How would I store the initialization vector for use when decrypting.

This entirely depends on the protocol. The IV can be either stored, or derived deterministically in a way that is guaranteed to be unique (such as from a session ID, packet number, or monotonic counter).

  Finally how strong is a key that is a created by the user?

If the key is composed of at least 16 completely random bytes, then it should be sufficiently secure that brute force attacks will not be an issue. Note that RC4 is still not a great cipher even if the key is very strong. Even when dropping the early keystream, there are still long-lived biases that can be exploited


It would not work very well, as far as I can see. Proxying (as well as SNAT/masquerading) requires much more than simple IP forwarding.

Let's see, say that

192.168.1.1 is your network gateway
192.168.1.2 is Alice
192.168.1.3 is Eve
192.168.2.2 is Bob.

Eve sets Alice as her gateway, and pings Bob. The packet arrives to Alice who then forwards it to the real gateway, whence it would arrive to Bob marked as Eve's. Bob would answer and the reply would be sent directly to Eve, bypassing Alice.

So Bob will never know what happened, and will hold Eve responsible for what Eve did.

The only thing is that now Alice gets to eavesdrop one side of the conversation.

So now Eve forges a packet as coming from Alice. Alice receives a packet from her own address coming in from the outside, and in all probability she drops it.

Eve could forge a packet belonging to Charlie, but then, she could do this even before, without Alice's forwarding support. Actually, she could forge anyone in the local network; by setting Alice as the gateway, she is now worse off, for she can forge anyone except Alice.

If she has some way of foreseeing Bob's responses, she can engage in a blind spoofing of the conversation (but again, she could do this before), if she can make it so that Charlie does not respond by aborting the connection, and that the gateway doesn't inform Bob that Charlie's not reachable. Also, for connection protocols such as TCP, "foreseeing Bob's responses" is not all that easy unless Bob's TCP stack is vulnerable to prediction.

If the real gateway has security on it, now she can make it look as if Alice was forging a packet from Charlie, so that the real gateway spots the forgery and believes Alice to be responsible.

This last seems the most feasible "attack" that Alice exposes herself to by providing forwarding services.


OCSP Responder certificate - CRL distribution points and AIA OCSP URI

In a definition of certificate profile for OCSP Signer certificate, should I define CRL distribution points or AIA OCSP URI?

RFC 6960 allows such configuration, however in practice there is no real benefit, because you will have other 3rd party source to validate OCSP signing certificate. When OCSP signing certificate includes id-pkix-ocsp-nocheck certificate extension, it is not validated for revocation.


Why no support for TCP Sockets in JavaScript

... but what is the issue with providing a socket API to allow interacting with existing protocols?

This is not a restriction of the language itself but of it's use inside the sandbox within the browser. Just imagine that a script somewhere on the internet gets loaded into the browser and could from inside the browser access every computer reachable by the browser with arbitrary protocols. You could easily misuse this to send spam through a companies internal mail server or attack/misuse other internal and external resources.

Which means there must be some restrictions in place and the different sandbox environments for the different language runtimes provide different kind of restrictions:

With flash the target host must explicitly allow access to by providing an appropriate socket policy file. This is similar to the mechanism within HTML5 CORS.
Untrusted Java applets are limited to communication with the host providing the applet.
And with JavaScript inside the browser you can talk to almost all sites, but you are limited by the protocol you can use, i.e. HTTP (restricted by CORS) and WebSockets.


Are their any consequences to encrypting a one bit message? Does size/variability matter?

There are actually two parts to this question. First, the minimum size of the encrypted message will be much larger than a single bit. This is done to prevent the scenario you describe. See this question for details.

Second, here's an explanation of why decryption (or determining the private key) won't be any easier, even if you know the public key, the message, and the encrypted version of the message.


Unix command to generate cryptographically secure random string

No, it's not entirely secure. Let's look at each of the commands:
dd if=/dev/urandom bs=256 count=1 2> /dev/null

This will read a single 256 byte block from /dev/urandom, a cryptographically secure random source. The problem starts here, and is related to this 256 byte limit. In fact, you do not even need to use dd here. The next command is perfectly able to read from a block device on its own.
LC_ALL=C tr -dc 'A-Za-z0-9'

This command strips out all characters that are not alphanumeric. The LC_ALL=C limits the charset to plain ASCII, where [:alnum:] will match 62 characters. Symbols and unprintable characters will be removed. The issue now is that only 256 bytes are given to this command, so what if too few of those bytes are alphanumeric? The tr command will happily take 256 bytes of input and spit out only a couple bytes of output if only a couple bytes match the filter.
head -c20

This command simply truncates the output to 20 bytes. The actual output will vary between 0 and 20 characters.* Statistically, it is most likely for it to output the entire 20 characters each time.

A superior way to get random alphanumeric characters can be done with fewer commands. This will have tr read as much data from /dev/urandom as it needs, continuously spitting out alphanumeric ASCII to the next command. As soon as head has the 20 bytes it has asked for, it will close the pipe, causing tr to stop reading random data and exit. This is what you should use:
LC_ALL=C tr -dc '[:alnum:]' < /dev/urandom | head -c20

This will guarantee 20 random characters, with an equivalent strength of log2(6220) ≈ 119.1 bits.
You can also turn this into a shell script function to make password generation from command line easier. This particular function takes the number of characters for the password as an argument. If no argument is specified, it defaults to 20 characters:
newpass() {
    LC_ALL=C tr -dc '[:alnum:]' < /dev/urandom | head -c${1:-20}
}

* The risk is largely theoretical. Each byte has a (256 - 62) / 256 chance (about 76%) of not being alphanumeric. The probability that at least 256 - 20 bytes are not alphanumeric is very low, but non-zero: (194 / 256)236 ≈ 3.8 × 10-28.


Is it a security risk to give read/write permissions to /Library/WebServer/Documents to my main account?

Yes it can be a security risk and can be considered as a security breach if your main account gets compromised or if you do something wrong by mistake - it differs from case to case depending on how important your project is and what you are dealing with. But if I were you, I would never use 777 permission or even something similar that anyone can easily make changes to my WebServer Directories. In other words, even if I own two Unix Users, one my X user and the other the root user, I won't give permission to X only because I'm looking for ease. On MacOS, like on Linux or any other Unix-Like OS, you can use ACLs - Access Control Lists -, you can set Attributes, or you can configure Apache in a way to have different root directories for different virtual hosts if you are going to deal with hundreds of users being in need of changing their own odds and sods inside the apache directories, but never underestimate DACs. Permissions that you mentioned are considered as DACs (Discretionary Access Control), 3 bits for the owner, 3 for groups, and 3 for others - also called staff. Anyway, I recommend you read about ACLs, I guess they will do what you need, default ACLs are used for granting/setting access control list on a specific directory to allow specific users and groups to have access right. For a quick insight on ACLs, you can use chmod with +a option to set or -a option to remove ACL. You can also you ls -le to display set ACLs. For instance:

chmod -R +a "group:_www allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" yourDirectoryORFile

ACLs are a better option - than changing permissions - that you can benefit form.

By the way, you should notice that that it is right that MacOS is safe and secure, but services including Apache, SSH, SAMBA, etc. are not secured since they are using and configured by the default state.

File and Directory permissions are one of the very basics and first permissions you will face with in Unix-Like Operating Systems. To secure your system, you really need to pay a close attention to every detail of the system depending on your purpose. Giving a full permission seems like you are deliberately providing security breaches in your system.

When it comes to Apache Server - or NGINX - you should first make sure about your directory safety. For instance in Linux, it's recommended not to disable SELinux (used for managin Mandatory Access Control, Role-Based Access Control - RBAC - and etc.), so in that case, after setting right permissions for directory and files, you can set roles and types in a deeper level of security. If it wasn't needed, everyone would use 777 - Read-Write-Execute for all Users, Groups, and Staff, so be sure there is reason why it isn't 777 by default.

And the next thing you should beware of, is your Firewall configuration and rules. MacOS is using PF since it's built on top of a FreeBSD microkernel (PF stands for Packet Filter - and IPFW stands for IPFireWall). You can use man pfctl to read its manual page and understand how you can deal with it.


Adding new keys to a server that doesn't accept password login

You could set up an ssh-proxy tunnel on the authorized Laptop, opening up a listening port, and connecting it through your ssh tunnel to the PI, then send the file through that, but I'm not sure that is any easier or more streamlined, then just (as you correctly said) copying the file to the laptop, and transferring it from there.

It might save you time in the future if you end up needing to do it multiple times though.


Could PDF's `/Filespec` type allow for remote file access?

I'm not sure about the feasibility of what you suspect. A library able to work with pdf files may not need to process such Filespec entry to perform its work (for instance the Filespec -if not an embedded file- could be referring to a font, only used when rendering it). And I suspect any library will not enable reading of external files without explicitly enabling such feature, as it could lead -as you note- to nasty surprises.

However, in case of doubt, and given that these are complex programs dealing with a nin-trivial format, I would apply the precautionary principle and process them in a sandbox/chroot/firejail/docker container, so even if the programs processing the pdf could be directed to open arbitrary files they actually can't open any sensitive file, only the standard files that were included inside the sandbox.