Is CSRF possible in an SSR SPA with cookie authentication?

Now if the user wants to delete their account, they could press the button, which would send a request to the API that authenticates requests only by Authorization header

Ultimately, it sends a request to perform an action which needs to be authenticated somehow. And, since you're using Authorization header for authentication, it somehow prevents CSRF unless you're using HTTP Basic Auth or NTLM. These authentication tokens are sent in each request similar to cookies.

  I mean I can't think of a way I can be vulnerable to CSRF in this situation, even if I use cookies for authentication, and as far as I understand, CSRF attacks can't scrape data out of web pages, so returning sensitive data shouldn't matter, as long as it doesn't trigger an action

There are situations you might find yourself vulnerable to CSRF, here are few;

What if your server accepts any of two i.e. either cookies or token?

-> I had recently encountered the same. The application would either need cookies or auth token. Since, cookies are always sent, you're assumed to be authenticated and your request gets processed leaving you vulnerable to CSRF again assuming your application allows sending Authorization token from any domain.

What if your application leaks auth token which can be read cross-domain?

-> I have seen a number of apps fetching tokens from a predefined endpoint which somehow can be read crossdomain. Some possibilities are, JSONP, CORS, crossdomain.xml, JSON Hijacking, etc. This again leads to CSRF.

  even if I use cookies for authentication

That is always vulnerable, you just need to play with final request which is an API request in your case.

  So my question is, is it fine to not implement any sort of CSRF protection in this case? I'm so afraid of having a security issue regarding that

As a matter of fact, yes. Also, make sure you whitelist domains which can make request to your API and return Access-Control-Allow-Credentials: false.
This, in my opinion, makes it fairly safe against CSRF- considering points mentioned above.


Best protection against a "chosen-ciphertext" attack?

Firstly, a little crypto background. I'll provide you with links and you can decide how far you read.

The key to avoiding CCA/CCA2 (Chosen ciphertext attacks) is to not provide an "oracle" (something the attacker can query either in a limited fashion or at will). In terms of practical implementations of such oracles, replying to encrypted email messages with the stuff you previously decrypted is an example of providing an oracle - whatever ciphertext went in has been decrypted and provided to the attacker. , a m

The key is to not provide that oracle, to which there are two solutions. One is to encrypt-then-mac - i.e. use a pre-shared secret to produce a message authentication code which the recipient can check before decrypting. That way, if the ciphertext is not from the sender, you reject it. An alternative to this is to use an authenticated encryption mode, a complete, integrated approach (it combines your block cipher with a MAC).

So the approach to solve the CCA/CCA-2 problem is to use some kind of authentication of your messages.

What can you do now? Read about the protocols your ciphers use and ensure they use something like EAX, or a MAC.


what is a security association and how does it relate to ipsec?

"Security Association" is the big name for whatever a machine A needs to know in order to send IPSec-protected packets to a machine B. Within the memory of A is the information: "with B, packets must use this type of IPSec header (AH or ESP) with these cryptographic algorithms and that specific key". By definition, when machine A talks to machine B and uses IPSec for such communication, then there must be some convention between A and B about how this will be done. "Security Association" is the defined terminology to describe that convention. How a security association is established is another matter -- it can be manual configuration by sysadmins on both machines, or done dynamically with a protocol such as ISAKMP.


Does Nmap requires a closed TCP port to do OS fingerprinting?

I've already written an answer to another question that details all the reasons a fingerprint may be non-ideal, but the short answer is yes, Nmap requires a closed TCP port to get the best match. But I'd guess that there are other things interfering with your scan if it's showing Nginx running on Windows CE.

Based on your output, I'd guess that the first scan used -d or -vv, but the second scan did not. The logic in output.cc says that the "No exact OS matches for host (test conditions non-ideal)." line only gets printed if there is a "reason", but the only condition under which the "reason" is not shown is if verbose is less than or equal to 1 and debugging is not turned on.


Is there any added security benefit to username complexity requirements?

I cannot think of a tangible security benefit, other than maybe possibly it being a little more difficult to enumerate the user names.  Some practice of security through obscurity, i would think that would have the disadvantage of then requiring your users to have to write down their username to remember it, maybe defeating the purpose of a complex user name.

On the other hand, I'm not certain how prevalent it is to use keystores like KeePass; sort of making remembering the username irrelevant.


Is it a coincidence that the first 4 bytes of a PGP/GPG file are ellipsis, smile, female sign and a heart?

Yes, it's a coincidence that the first bytes appear to you as these symbols. They are part of the OpenPGP message format specification (RFC 4880) and vary depending on the packet properties.

Let's create a file containing only those bytes and try to read it as a GPG message:

$ echo "\x85\x02\x0c\x03" > foo.gpg && gpg --list-packets foo.gpg
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 255, keyid 0AFFFFFFFFFFFFFF
    unsupported algorithm 255

The first byte (0x85 = 0b10000101) is the cipher type byte (CTB) that describes the packet type. We can break it up as follows:
1: CTB indicator bit
0: old packet format (see RFC 1991)
0001: public-key-encrypted packet
01: packet-length field is 2 bytes long
The second and third bytes denote the packet length (0x020c = 524).
The fourth byte (0x03) means it's in the version 3 packet format.

As you can see, these bytes are meaningful and not magic number constants that you can remove without losing information. If you cut them off, you are corrupting the GPG packet and it will require some guesswork to reconstruct it.

The bytes are shown as smileys and hearts because that's how your (probably DOS) terminal displays non-printable control characters. In character sets that originate from code page 437, low bytes outside the printable ASCII range are traditionally represented as icons. Here's the original CP437 on an IBM PC:

(Image source)


What should be in top-down IoT Security Policy for companies engineering products to market?

How to build a secure IoT device

IoT devices cover a wide range of functions, from Smart Meters to Web Cams. This includes very simple devices, such as smart light bulbs, and more complex ones, like voice control hubs.

Convenience is important when setting up IoT devices. Most consumers opt for simpler setup processed like "WPS Push Button". This is probably not a big problem as attackers need physical proximity at a specific time.

Network Security

There are three main network security models for IoT devices:

Local automation hub
Connect to manufacturer
Provide a listening service

Local automation hub

The device makes a connection over a local network to an automation hub. Typically, a device will pair with the first hub it finds. There is a small window of vulnerability, but after that communication is encrypted. Sensitive systems may need more secure key distribution. Once connected, devices usually fully trust the hub.

Connect to manufacturer

The device makes a connection over the Internet to the manufacturer. To do this securely, there should be a certificate hardcoded on the device that validates an SSL connection. Once connected, devices usually fully trust the manufacturer.

This relies on the provider to keep their service secure and available. Some consumers dislike the requirement to trust a third party. This arrangement tends to be secure, but is only suitable for some devices, e.g. smart meters.

There needs to be a secure process to associate a user's online account with the manufacturer, with their device. Failure to do this results in vulnerabilities like this Nissan Leaf vulnerability.

Provide a listening service

The device listens on a port, typically providing a web server. The user can expose this to the Internet using port forwarding; the device may automatically expose it using UPnP.

Authentication is essential; normally this is done with a password. There are three approaches to setting the initial password:

Default password, same on every device. This is very risky, results in many compromises, and is not recommended.
Random password, unique on each device. The password can be printed on a sticker attached to the device.
User sets initial password during install. This leaves a small exposure before a password is set.

Many users want to change the password to something memorable. This creates many risks - users tend to pick bad passwords and re-use passwords many times. To mitigate this, there must be: a password strength policy, a lockout policy, and passwords must be stored hashed, with a salted, computationally expensive hash.

Secure development

IoT software must be coded carefully to avoid exploitable vulnerabilities, such as command injection, which have been prevalent in IoT devices. Embedded systems are a challenge as there is limited memory. Many routers run BusyBox and have Bash scripts acting as CGI scripts. This is risky as it's very easy to accidentally introduce command injection flaws. Consider using a different embedded system, such as LUA.

The device should require authentication for all requests. This greatly reduces the attack surface. For example, this Netgear vulnerability would have been much less serious if only authenticated users could exploit it. Thorough CSRF protection is also required, or external web sites can send cross-domain requests through a logged-on user's browser.

All network connections should be encrypted. Use SSL with only modern protocols and ciphers enabled. There are several good embedded SSL libraries, such as Tiny SSL. IoT devices typically have a self-signed certificate. This is acceptable, as long as the certificate is unique on each device.

Most devices use a lot of C code, which could be vulnerable to memory corruption flaws. Enable all the anti-exploitation features available (stack guard, DEP, ASLR, etc.)

You need to audit your code for bugs. This should include both static analysis (code review) and dynamic analysis (pen testing and fuzzing).

Physical security

Most IoT devices don't defend against physically local attackers. Those that do (e.g. smart meters) can take basic precautions like disabling the JTag interface to make attack much harder. More advanced anti-tamper precautions are possible.

Software Updates

Most devices should have an auto-update system that is enabled by default. The device must only accept signed updates, and there needs to be protection against downgrade attacks.

Logging

Logging poses a privacy risk, especially in devices with microphones. We need to weigh the usefulness of logs to the user against the privacy risks. In most cases IoT devices should keep limited logs. One useful log: listening services should log all connection attempts - with successful and unsuccessful authentication.


Can anyone with access to root CA private key decrypt HTTPS traffic?

No, this is not the case.
A certificate signed by a CA contains only the public key, but for decrypting you need the private key too. This private key is not needed for the CA to sign the key, so they usually don't have it either.

But, some CA offer to simplify the process of certificate generation by generating a key pair for the certificate too. In this case the CA knows the private key at least for a short time and the owner of the certificate has to trust the CA to forget the key after certificate and key were downloaded by the owner of the certificate. This is much more trust than just the signing of an existing CSR (which does not contain the private key).

Apart from that even private key does not help to simply decrypt sniffing traffic if the key exchange is done with Diffie-Hellmann (DHE, ECDHE). In this case the attacker would need to mount a real man-in-the-middle attack to actively intercept and modify traffic.


Specific clarification on how https server public key is trusted

I can understand that large CA have their certificates already installed on the client machine

That's it. It's just preloaded on the clients. No magic.

You need to get your trust anchors (root CA certificates) onto the clients BEFORE you can start reliable HTTPS. There is no way around that.


Are backups of truecrypt volumes with different pass phrases a security risk?

The only issue would be that the expected time to brute-force the password would be significantly reduced, by a factor equal to the number of volumes they're given.  So for example, if they are given 5 volumes, it would take 1/5th the time to brute-force the key, under the (highly dubious) assumption that testing the key on 5 volumes takes just as long as testing it on one.

This is probably not a major concern, however; even if you used "only" a 128-bit key, and the attacker had a million volumes to work with, your effective security would only be reduced by 30-bits, leaving a still-hefty 96-bits of security.

So, as long as you don't choose to encrypt with an algorithm that has a serious plaintext vulnerability (none of the algorithms used by TrueCrypt currently do), you should be fine.


HIPAA non-business associate for contract work

Yes, that is correct.

Based on your agreement, if you are building anything that touches (stores,transmits, or manipulates) PHI (Protected Health Information), you must meet HIPAA security rules (164.312 Technical safeguards) by the book.

It covers only covered entities and BA-s but as a non BA vendor you are responsible to meet or exceed the standards and to show due diligence, being a non BA vendor liability is not shifted, you can and should have and EO or other professional insurance to mitigate risk.


This is because your program was compiled as a position independant executable (PIE). Instead of the addresses being hardcoded into the binary, they are only stored as offsets from 0, which explains how you are seeing addresses such as 0x000000000000113d. At runtime, a randomized base address is generated, and all sections of the executable will exist at offsets from that base.
When you are running disassemble main, gdb is disassembling the executable itself without taking into account the runtime addresses. In fact, there are no runtime addresses yet since you haven't started the binary. If you want to see the actual addresses, you will need to try to disassemble again after execution has started.


Extracting shellcode from Wireshark pcap files

You can open the PCAP file with NetworkMiner, which will automatically extract all files that have been trasfered in clear text (HTTP, FTP etc). NetworkMiner woks in both Windows and Linux.


Nmap scanning computers behind a wireless modem

For the most part, you can't.  NAT acts somewhat like a firewall with a "default deny" rule.  Unless you set up a DMZ or port forwarding, a computer on the "internet" side of the router cannot make unsolicited contact with the computers on the "private" side.


How can I disable javascript alert and access the webpage?

You can disable javascript in your browser, then download the page. For mozilla firefox go there :
mozilla docs.


Exploiting XSS in jQuery without equal character?

I think it is safe to say at this point that there is no trivial/text-book bypass for this filter using a modern browser. I shared this snippet of code with a group of friends and colleagues who I consider proficient in XSS and none of them could construct a bypass.


What to do? Can they compromise my wp data?

First and foremost, fix the vulnerability and/or how it leaked. Usually, an update should fix such vulnerabilities if they're from plugins/themes or WordPress core itself. If not, you can at least block requests to path that you saw on your access log, assuming it's 100% a leak.

Then, change your salts from
https://api.wordpress.org/secret-key/1.1/salt

And yes, change your database credentials and update everything accordingly.

They cannot compromise anything unless-

You have MySQL remote connection enabled or
You have a phpMyAdmin/Adminer exposed or
You're on a shared hosting or
You use the same password for your other accounts


RoRaZ and 40F4 made some real good points.

Another thing is, that especially in the health sector or finance sector, respectively in any enterprise that needs to use software specially crafted for their exquisite usage, it sometimes might not be possible to update the operating system without causing bugs in essential and expensive software that cannot be easily replaced. Especially hospitals work a lot with rather old Windows versions, making them highly vulnerable. Next thing is, it's not only the desktop systems; any (e.g. medical) device can build up on an operating system like Windows, and from what I learned those hardly ever receive any updates.

Just because there are fixes that doesn't mean that fixes are an easy option to take for everyone. The private user will not be concerned by this problem, but the private user is rather seldom the target group for exploits like EternalBlue.

Addition:

0xffffffff ffd00000 is the virtual address for 64-bit systems, if it is 32-bit, then it is just 0xffd00000


Trouble understanding how passwords are authenticated

I read through the material and reread the Wikipedia entry on PBKDF2. I think I understand your confusion. PBKDF2 is a standard developed for how to derive a password verifier - it is an algorithm, but it doesn’t specify the exact details as it leaves some particulars open for implementation. These include the particular hashing function or PRF, salt size, iteration count and length of the output (key length). I’ll get back to all of this below.

Next, the article mentions cryptographic hash. What they mean by this is SHA-1 or MD5 or one of their brethren. Think of a cryptographic hash as a raw building block developed by cryptographers and designed to meet a certain set of constraints, in particular robustness in the face of known or discovered attacks against prior hashes including improvements in computing power. Also, why is the cryptographic part important? Because simple hashing that you or I might invent would be easily broken, whereas the hash algorithms cryptographers invent are resistant to various known attacks. There was a time when passwords could be stored in plaintext. People didn’t know how to break into the system files and recover the passwords. However, admins could see the raw passwords and sometimes certain system operations could be tricked into revealing passwords. Subsequently, passwords were hashed with any old algorithm and then cryptographic hashes.

The problem with cryptographic hashes is that hackers could steal the password tables/files and use rainbow tables to match passwords. I may not know your password, but if I have its hash and I run a dictionary through the hash algorithm and a result matches the hash, bingo! Now, offline I can just build a large database of every word or sequence I choose at my leisure and anytime I get any password hashes, I match them against the prebuilt table.

In comes salt. The salt, which should be the same length as the cryptographic hash output length, kills being able to prebuild a rainbow table. Every password hashed with a unique salt means even if two people share the same password (unknowingly) then no one could compare their hashes and discover that fact. The salt may be kept in the clear. It is not a secret, so much as a rainbow table nullifier.

Once computers became really fast, it became important to further thwart hash breaking attacks on the chance someone steals your password hash table. To do that, security folks decided that just doing more rounds of hashing would address the problem. Think of a cryptographic hash as really a KDF with only one iteration. Instead, some folks recommend 10,000 iterations.

Finally, we get to the KDF (Key Derivation Function) part. In the KDF, we combine a password (plus perhaps a username) and a salt and run it through some particular cryptographic hash 10,000 times. There’s the added bit of the PBKDF2 standard which allows you to suggest the output length. You might want to use the PBKDF2 to generate a key for a encryption algorithm or to pass to some other cryptographic function. The standard suggests a secure way to smear entropy bits throughout the entire output without risking reversing the inputs; always a problem for security protocols.

With all of this in mind, to answer your questions: (a) store and use the results of the PBKDF2 directly, there’s no need to apply any other operations on the password verifier and (b) in your list of steps at the end step 3 isn’t really needed and step 2 does all of the work including running many iterations of a cryptographic hash to create the PBKDF2 output.


Reversing a block hash of SHA-1 with known Plaintext?

Recomputing secret from SHA-1(secret || suffix1) (for any known value of suffix) would constitute a preimage attack. No preimage attack faster than luck is currently known for SHA-1 ("luck" works in average effort 2160 for SHA-1, i.e. totally infeasible). You won't get the secret value.

However, if your goal is to compute SHA-1(secret || suffix2) then that one may be possible, depending on the value of suffix2. It is called the length extension attack. Namely, suffix2 must begin with suffix1, followed by some padding bits which depend on the length of secret || suffix1; after these bits (which you do not choose), you can put whatever data you want. In that sense, suffix2 is partially controlled by the attacker.

Length extension attacks are sufficient to show that SHA-1(secret || data) is a poor MAC, and HMAC should be used instead (all of this applies equally well with the SHA-2 functions, by the way).

Now if you do not want to put any constraint on suffix2, then this is going to be hard. The effect of secret boils down to an unknown 160-bit state at the start of the second block. I don't have time this morning to work this out mathematically, but my intuition is that finding that state value from the output of SHA-1(secret || suffix1) would be equivalent to exploring a cycle in the permutation incarnated by the SHACAL block cipher with suffix1 as key (assuming suffix1 + padding fits in one block). Since SHACAL is supposed to be a "good" block cipher, this permutation should behave as if chosen randomly among the set of possible permutation of a space of size 2160, meaning that the cycle should have, on average, a length close to 280. This again implies a cost too high to do it in practice.

Note that being able to do what you try to achieve would not contradict the properties of SHA-1 as a "good hash function" (resistance to collisions, preimages and second preimages). It does not mean that we don't care about it, but it highlights why hash functions and random oracles are not exactly the same thing.


Is password reuse a problem if the password is very strong?

Password reuse is a security bad practice because of of a simple attack scenario like this one:

Source: XKCD
With reusing a long and complicated password, you are still facing the same threats as highlighted in the above schema.
In addition to this, saving a password in a text file is an unsafe practice in that the privacy of your password depends also on the safety of your computer (think of malicious browser plugins you may install, drive-by download attacks installing spyware on your machine ...) and that of your network. You may also consider other scenarios like with phishing attacks on which the strength of your password does not play a role.


Can a Ubuntu live usb be infected with spyware/ virus?

Of course it can. I presume you didn't make your USB stick irreversibly read-only in hardware (can be done, but it's rather fiddly, and in case of using the read-only switch, it can of course be easily moved back in write position, if your drive even has one), so what you got back on your stick could be anything, unless you check that the complete contents of your drive match the ones you gave away.

The easiest way out is probably by formatting the drive and reloading it with a new copy that you hold and nobody could tamper with, or downloading it again from a trusted source. Alternatively, you could calculate checksum of all the files on the drive, and compare them and the rest of file metadata (like timestamps) with those you calculated and noted previously, or the ones you find online where you downloaded the files from, to check for evidence of them being tampered with.


How to prevent security risk when logout failed for authentication cookies

Use a second cookie on top of the session cookie. When logging in, put some random data in that cookie and in the session. On every access, check whether these match. On logout, remove this cookie on the client side.

This second cookie is not HttpOnly, so you can remove it using JavaScript. To perform authenticated requests you need both cookies, and an XSS attack can't read the session cookie as its HttpOnly. So you get the advantages of HttpOnly while still being able to revoke the session on the client.


Securely storing a master key client-side

It is possible that the master password is asked to the user one time during the start of the app and, then, it will stay stored only in the RAM.
This way, the master password doesn't need to be written on the persistent memory (hard drive), so it is pretty secure.
But this schema does not allow the app to have a "forgot password" feature.
If the app need to have advanced features like the forgot password, it needs to store some secrets permanently. One way is to use the dedicated interface provided by the OS.
Many OS have a kind of software HSM which is dedicated to store secrets of the computer in the behalf of the apps (DPAPI for Windows, keystore for Android, ...). These software HSM are designed to implement all the protections against a physical attacker. So, even if no one of them are unbreakable, they try to slow the attacker as much as possible.
The best protection is the real HSM (H for Hardware) which is unbreakable without a significant money cost gear


Most efficient key algorithm for a TLS server key?

With a modern but not-so-speedy x86 processor, and a good enough implementation, cryptography speed will not be the bottleneck. For instance, consider a quite cheap AMD Athlon 2650e processor, a not-so-modern and really-not-so-speedy processor that I have in my home file server; it is clocked at 1.6 GHz and has a single core. It can still do about 2200 RSA private key operations per second (for a 1024-bit RSA key). I seriously doubt that the Linux kernel on which this machine runs can cope with 2200 new TCP connections per second...

(Note that for anything related to RSA, running an x86 CPU in 64-bit mode is a huge win -- that's what I do with my cheap server, by the way. In 32-bit mode, divide the figure by 3 or 4; this would still be quite respectable performance.)

Also, SSL/TLS has a feature known as "abbreviated handshake" which is about a client connecting again and reusing the asymmetrically exchanged secret of a previous handshake. See section 7.3 of the standard. The abbreviated handshake involves symmetric cryptography only, no RSA. Note that, in practice, the best thing about abbreviated handshake is that it implies less network packets and lower latency; the lower CPU usage is nifty but not so visible when actually measured.

Assuming that you nonetheless find the asymmetric part of SSL to be huge on the CPU budget, your best bet will still be a "plain RSA" cipher suite, although there could be a tie with ECDHE cipher suites (but the only elliptic curve which is decently supported by existing clients is the P-256 curve, which is fine but somewhat an overkill if you just aim at 80-bit security).

SSL/TLS also uses symmetric cryptography, and that one can use some CPU, too. An x86 CPU is more than powerful enough to encrypt all data which can go through a 100 Mbits/s link, but you can have some savings if you choose your algorithms properly. In practical terms, this means: use AES or RC4, not 3DES. AES will be exceptionally fast and cheap if your CPU offers the AES-NI instructions (and if your SSL implementation uses them, of course).

For the hash algorithm, MD5 is somewhat faster than SHA-1, but SHA-1 can already process 240 Mbytes/s (mega-bytes, not megabits) on my cheap AMD CPU.

So this points at TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA to be the cipher suites of choice for who wants to get the most connections per second for the least CPU. Or possibly TLS_ECDHE_RSA_WITH_RC4_128_SHA or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which will be less widely supported, but will give you Perfect Forward Secrecy, which can be a nice thing to have.

This being said, performance can depend a lot on architectural details and the exact operation environments, therefore you shall measure. Try it and see if changing the cipher suite makes any actual difference. Remember that performance has often a lot more to do with the amount of efforts invested in the protocol implementation, than with the intrinsic merits of the algorithms themselves.


I guess you are looking for this tool

  Pyrit allows to create massive databases, pre-computing part of the IEEE 802.11 WPA/WPA2-PSK authentication phase in a space-time-tradeoff. Exploiting the computational power of Many-Core- and other platforms through ATI-Stream, Nvidia CUDA and OpenCL, it is currently by far the most powerful attack against one of the world's most used security-protocols.

Honestly, I never used Pyrit, but it seems like a good piece of software. The Google Code Page holds some tutorial and setup instructions. As Pyrit takes traffic dumps in the pcap format, you can record Wifi-Traffic (the more, the better) and analyze it some other time or place.

You might also want to have a look at here: GPU-Based Cracking @ Tom's hardware. This site covers some staticstics on average cracking times. Even though Pyrit exploits the computational power of your graphics card, the cracking of a various 6 digit alphanumeric password will take at minimum 3 days.

Pyrit on GoogleCode

BTW: The BackTrack Linux Distribution (A LiveCD for penetration testing) comes with Pyrit preinstalled.


I just had to use the shell command in the java meterpreter in order to correctly be able to execute the .exe and get the windows meterpreter session running.


How to brute force HTTP Basic Authentication requested with XHR?

Metasploit's http_login module doesn't support arbitrary HTTP headers.  If the site only responds with the XHR header included, then you might want to use a more versatile tool like hydra.

# indicates the beginning of the URI fragment.  This isn't a part of the URI used for logins, but is typically used to pass options to the front-end web framework.


Should you let yourself ssh into every machine in your network?

This is a great question becuase this is a common concern I deal with. I will give some answers into what you should understand and what I would do.

Bastion Host or JumpBox is just two step so you can log in to the AWS via SSH port 22 or RDP port 3389 as you already know (for new users reading). It is a way to secure and to let your instances and not let your instances be in a public subnets (expose to the internet). Which means you need to access the jumpbox (Bastion Host) and then connect to the instance which is in a private subnet (no internet access). If you have multiple instances this will save you alot because you will only have to manage the security of the bastion host.

Opening ssh to the world is a very dangerous practice. For once when you create an instance in amazon it generates a keypair .pem so you can connect to your ec2 instances. The issue is managing the keys. If we talk about an organization as an example many users will have keys that will be an issue, and will fall out of hands if the instances are exposed to the internet and also its not a good practice to share keys between users for the same instances.

Resume:
So between these point what I would suggest if its that much level of security that you want is that you may want to look at something called SSM. SSM is an agent that is installed in your instances that monitor the instances, you can block all ssh access including in a provate subnet. And you can only connect trough it via the AWS Console (Picture below). You will not need a bastion host nor opening your instances up to the world via an ssh port. Which means you will save costs and also provide better security. Another point is you will have full to the instances (logs, healthcheck and control) trough the IAM which you can authorize which user or resource has accesss to it.

Login trough the SSM
Observation : These are all in a private subnet and I use an Internet Gateway to download dependencies from yum.


user authentication by decrypting a random blob

The most basic authentication scheme looks like this:

Client knows password.
Client shows password to server.
Server is happy.

Password hashing is done only to counter a secondary threat: that some bad guy succeeds at having a peek at the server files or database, through some illicit but common way (SQL injection attacks are usual). We don't want that bad guy to immediately learn all the user passwords. That would be inappropriate. To avoid that, the server will not store the passwords themselves, but only some values which are sufficient to verify a password. This is where hashing occurs. The server hashes the passwords, with a slow and salted hash function, so that the envisioned attacker with sharp eyes will at least have to perform some substantial work for each password he will recover.

But that hashing is entirely a server business. The client does not see it. From the point of view of the client, the protocol is just "show the password". How the server decides that the password is the correct one or not, is completely irrelevant to the client.

The basic protocol is usually sufficient because it will be played within SSL (aka HTTPS in a Web context), which ensures that the client has some a priori guarantee that it is sending the password to the right server, and nobody else can spy on it. We need something like SSL anyway, to prevent the connection from being commandeered once the authentication has been done. So we might as well use it and just show the password to the server.

Nevertheless, some other protocols have been designed, in which the raw password is not shown to the server. Motivation is either distrust of the security guarantees provided by SSL and its digital certificates, or just disregard of the risks of hostile hijacking (the protocol is played "in the clear" and it is just assumed that attackers are passive only -- a singularly optimistic stance, verging on the naivety, but it was much more common in the late 1980s and early 1990s). These are challenge-response authentication protocols. Your proposal with the "encrypted blob" is of that kind. The server sends a value to the client (the challenge) and expects the client to process it in some way which involves the password (that's your "decryption"). The server verifies that the client properly responded to the challenge.

In general, challenge-response protocols are not a good idea. They have the following drawbacks:

The main benefit of a challenge-response protocol is to avoid showing the password to a fake server. But showing the password to a fake server occurs only if the client accepts to talk to a fake server in the first place, meaning that the transport medium can be subverted and allows replay attacks and men-in-the-middle. This is bad news. The overall situation is rotten and should be fixed in a much more thorough way than using a challenge-response protocol. Wearing a lifejacket is good, not being on board the Titanic is better.
The server must have a way to verify the response to the challenge. It is very hard for the server to avoid storing something which is password-equivalent. For instance, if the challenge is "you, client, decrypt this blob !", then the server must have encrypted some data to produce the challenge blob; otherwise, how would the server know that the decryption worked ? And to do the encryption, the server must know the encryption key, i.e. the password, not a hashed version thereof. You have lost the benefits of slow and salted hashing. Keeping the server's database invisible from the attackers becomes critical again.
If the server is fake (and you are using a challenge-response protocol instead of just show-the-password precisely because you deem it possible that the server is fake), then that fake server will still learn a value which is deterministically computed from the password, i.e. something which is sufficient to mount an offline dictionary attack (the bad guy tries potential passwords at the full speed of his GPU, on his own machines). That's not good. (Speaking of which, your suggestion to use the "hash of the user password concatenated with the username" as salt is not a salt at all, because of this determinism.)
A client who responds to a challenge is a client who can compute. This does not map well to a Web context. In a Web context, client code is Javascript, and Javascript is feeble; it is not good at computationally intensive tasks.

These drawbacks can be fixed, with another tool: mathematics. Maths are great. They allow a more recent and considerably niftier class of authentication protocols, called password authenticated key exchange. These protocols allow for mutual authentication (the client also gains some guarantee that it talks to the right server; they resist offline dictionary attacks (even a fake server, or a fake client for that matter, does not learn anything which would be sufficient for that), and the best of them avoid having to store server-side some password-equivalent data. The most oft-cited PAKE protocol is SRP. SRP has the additional benefit of being integrated in SSL/TLS, which is good because even with the best authentication protocol in the world, you still need something to protect whatever data you will send afterwards.


PHP: if charset mismatches (htmlentities UTF-8) viewed by client as ISO-8859-1 (or vice versa)

As far as I'm aware, there's no security issue.

The "dangerous" characters in HTML (less-than, greater-than, ampersand, single quote, double quote) all have identical byte values under UTF-8 and ISO-8859-1 (and virtually every other encoding you're likely to encounter, with the exceptions of UTF-16, UTF-32, and EBCDIC).  As a result, escaping them in one encoding will escape them in the other encoding as well.

The reason this holds true is that the vast majority of character encodings, including UTF-8 and ISO-8859-1, are "ASCII plus additional characters", and the structure of an HTML document only uses characters in the ASCII portion of the encoding.


How do I protect my OpenPGP key on my computer?

What's your threat model?

If your threat is that you are protecting from physical theft, then encrypting the key (using passphrase) or full disk encryption would suffice.

If your threat is a malicious program running under your user account, then you want to run potentially malicious programs in a sandbox, or just not run it at all.

If your threat is a malicious program with root access, then you should use an OpenPGP Card.


Does Adobe Acrobat Reader DC upload opened PDF files?

I don't think it likely that Adobe is automatically uploading your PDF to their servers.  Collecting all PDFs from all users would be a large about of data, without any visible financial gain.  If you want to confirm that your documents are not getting uploaded I can suggest the following ways:

Create a local proxy server which uses an SSL certificate which you
control.  You should then be able to decrypt any traffic sent to
Adobe's servers.
If the reader implements certificate pinning, or
setting up a proxy is not possible, try opening another document,
preferably much larger than the original. Make sure the document
does not compress well. If the size of the encrypted data in your
Wireshark trace increases significantly, then it's possible that
your data is being uploaded.

If you don't want to worry about your data getting sent off to Adobe, consider either blocking it at the firewall level, or adding a hosts entry to sinkhole any of the domains specific to the traffic you want to block.


As Ohnana also mentioned the way to request a formal CVE is through their intake form.

https://cve.mitre.org/cve/request_id.html

Details from a current snapshot of that website

Main Methods
Contact one of the officially recognized CVE Numbering Authorities (CNAs), which will then include a CVE Identifier number in its initial public announcement about your new vulnerability.

Or, contact an emergency response team such as CERT/CC, etc., post the information to mailing lists such as Bugtraq, or provide the information to a vulnerability analysis team.

Alternative Method
If you are unable to obtain a CVE Identifier number via the main methods above, you may request a CVE Identifier number directly from the CVE project. To reserve a CVE Identifier number before publicizing a new vulnerability, vulnerability researchers may contact cve-assign@mitre.org and we will provide you with our "CVE-ID Reservation Guidelines for Researchers" document. We will then work with you to assign a CVE Identifier number for the issue while you work through the process of publicly disclosing the vulnerability.

Please review the Researcher Responsibilities.
https://cve.mitre.org/cve/cna.html#researcher_responsibilities

Adding a link to the CVE FAQ.
https://cve.mitre.org/about/faqs.html


Possibly illegal material discovered through hacking - theoretical discussion

X should do nothing. X likely broke a few laws by hacking into the system controlled by Y, so by reporting it they are incriminating themselves. Should it come to a criminal case against Y, the defense of Y will likely be that any evidence X claims to have found was forged by X to incriminate Y. X admitted to being a cyber criminal, after all, so X can not be trusted.

What X should have done is inform the authorities when they thought Y looked and sounded suspicious over social media, let them decide if they want to pursue the case or not and forget about it.


Authentication followed by storage decryption on login?

It's usually a bad idea to encrypt user data with a key based on their password. What if they forget their password?

If you really want to, the "KDF" in "PBKDF2" stands for Key Derivation Function. So you could use that again to derive a key for the database. Remember to implement a mechanism to change the password as well. Depending on your setup, this might mean encrypting your database with a fixed random key per user, then encrypting that key with the one derived from the password. No PKI required.


Why did "terminal commands" never get a version of SQL "parameterized queries"?

Or maybe it is, only I haven't heard of it?

Many languages provide a way to give command and arguments as separate parameters and thus avoid any interpretation done by the shell. This addresses the same problem as separating SQL commands and parameters with parameter binding. For example in Perl:
system("pg_dump", "--format custom", "--file", $1, "--exclude-table", $2)

Similar functionality is provided by the various exec functions in libc where also command and arguments are strictly separated. Or subprocess in Python, os.exec.Command in Golang, system in Ruby etc. I did not find similar functionality in PHP though, i.e. it seems to insist on using a single command string interpreted by the shell with all the problems this causes.


Why does Double Submit Cookies require a separate cookie?

The reason is that this allows the main session cookie to be marked HttpOnly (so it won't be accessible to Javascript).  There is some debate about how much value this adds, but HttpOnly seems to make some kinds of attacks harder so is arguably a useful hardening measure.

If you didn't use a separate cookie, but just re-used the session ID for these purposes, then Javascript would need the ability to read the session cookie, and we wouldn't be able to mark the session cookie HttpOnly.  By using a separate value, it becomes possible to mark the session cookie HttpOnly.

This is why they recommend using a separate value.


Many common SQL servers support functions such as xp_cmdshell that allow the execution of arbitrary commands. They are not in the SQL standard so every database software has different names for it.

Furthermore there is SELECT ... INTO OUTFILE, that can be used to write arbitrary files with the permissions of the database user.  It may be possible to overwrite shell scripts that are invoked by cron or on startup. If the database server process is running on the same server as a web application (e. g. a single rented server), it may be possible to write .php files that can then be invoked by visiting the appropriate url in the browser.

The third way to cause damage is to define and execute stored procedures in the database. Or redefine existing stored procedures, for example a function that verifies passwords.

There are likely more ways.

The application database user should neither have permissions to execute the shell functions nor use INTO OUTFILE nor to define stored procedures.


Assuming that everyone always performs a revocation check, do we still need expiration time in each certificate?

Delivering the existing CRLs is a significant cost for the CAs!
Here you can see some information about costs.

  [...] CRL grow to approximately 4.7MB in size from approximately 22KB [...] around 40Gbps of net new traffic across the Internet [...] the traffic to deliver the CRL would have added $400,000USD to Globalsign's monthly bandwidth bill

If certificates would not expire, CRLs would grow forever and never shrink!


How should I securely generate random passwords when importing new users?

First of all, you need to use a secure random number generator, like Ruby's SecureRandom.

Second, you should choose a target security level for the generated passwords, i.e., how hard should they be to crack?  Security levels are often given in bits, i.e., the base 2 logarithm of the number of distinct equiprobable passwords.  In simpler words:

A 64-bit security level means that there are 2^64 distinct passwords, and your system is just as likely to be choose one as any of the others;
A "random assortment of 8 lowercase/uppercase letters and numbers" is 62 distinct characters, which means that choosing one such character at random provides log2(62) ≈ 6 bits of security.  Choosing 8 such characters independently at random provides log2(62) * 8 ≈ 48 bits of security.

48 bits is crackable in practice for a really dedicated attacker; I would recommend about a 64-bit security level as the bare minimum for passwords, and I prefer about 80 bits for my own.  With lowercase/uppercase letters + digits, you need 11 random characters for a 64-bit security level, and 13 characters gives you a 78-bit security level.

Before an edit your question asked about the effect of adding symbols to your passwords as well bumps the alphabet size to about 95 characters, and log2(95) ≈ 6.6, which brings those password sizes down by one character: 10 characters for a 64-bit password and 12 for a 79-bit password.  If you're generating passwords at random, you can therefore see that it's not a huge effect.


How to identify hackers based on ip addresses and the pages that were accessed

is there a way to see what company an ip address is assigned to?

You can find additional information about an IP address by using WHOIS services. ARIN, is a good start, and will redirect you to other registries (such as LACNIC or RIPE) when needed.

For most activity from legit search engine bots, the WHOIS will also contain the name of the company. For example, the WHOIS for 209.85.238.2 (one of the IP addresses used by Google crawler) will indicate that the IP address is registered by Google Inc.

You may also be interested by the lists of IP ranges by crawler, such as this one.

  Or, do those crawlers from search engines only go to pages that exist?

Not necessarily. A crawler doesn't always know that the page doesn't exist:

A page could have existed and indexed in the past and was removed later,
An internal link can lead by mistake to a resource which doesn't exist,
An external link can lead by mistake to a resource which doesn't exist.

  Here are some of the errors that I'm getting, should I blacklist this person?

It's your responsibility to decide to blacklist the IP or not.


How to exploit XSS vulnerability through an iframe

This is called Self-XSS.

It can be usefull if you can combine it with a csrf vulnerability on the auth.

Insert the XSS
Trigger a user to visit a controlled page
Use a csrf vulnerability to log off this user and connect him to your account
Redirect him to your infected page

Or as @reed suggest, use a csrf vuln to edit the link on the victim account and redirect him to the infected page.


May I use OAuth2 for non third-party applications?

Shortly speaking ROPC grant type plus OAuth2 will resolve your problem but it is not recommended for such a solution. The ROPC was designed in OAuth2 to only support legacy applications where no code changes are possible to use the more modern grant types.

As far as I understand your solution, you have an API layer that is hidden by API Gateway (of your own design) and a Keycloak as Identity Server.

There is couple of possible approaches but what you could implement is like this. AS afar as I know Keycloak can be used also as Authorization Server, so it can issue the access tokens taht can be used to access your respources. The access token should be issued with a desired SCOPE which desribes what API can be accessed by client. Next, because your APIs are not possible to be accessed directly, the Relying Party is your API Gateway so any request to API is just a request to API Gateway. It means that API Gateway have to consume access token. As consuming access token I undersantd that if client is requesting the "API A" API Gateway checks if access token includes scope claim with value related to requested API (check introspection endpoint in OAuth2 specs). If it is true API gateway will passthrough the request. If not, it will stop the request.

The best practice here is to use the "authorization code" flow. Please check also Implicit flow but it is not recommended now.

In this solution your Keycloak endpoint should be the public one because your users have to authenticate against it.


Youtube & Google Services that ID you based on stuff on your computer - what is the risk?

There is no way Javascript code could have access to information related to the WiFi networks in range. This may be possible using a Java applet or ActiveX, but I don't think it is very likely, as the user should permit the applet to run.

There is though another problem you should consider: DNS leak.

Explained here:
http://www.dnsleaktest.com/what-is-a-dns-leak.html

Also discussed here:
What is a DNS leak?


You should definitively restrict the range of your question and update the title accordingly. I'm answering here to your last question "has there been any successful injection attacks using camera input ?".

Yes, I think you can say so. I'm particularly referring to a vulnerability which affected Google glasses.

The Google glass would detect and handle automatically some type of QR codes, so some people had the idea to print specially crafted QR codes (exactly same principle as your SQL injection car plate, but here with a QR code instead of a literal string) which will automatically trigger this functionality in the Google glass and allow the attacker to take control of the Google glass internal system (accessing data, etc.).

No user notification nor interaction, all that is needed is for the malicious QR Code to be seen by the Google glass camera.


Is there a way to safely run untrusted code on a local machine for a videogame

EDIT: The question originally asked about running untrusted code in general, not about the specific scenario laid out above. For something like that, you usually want a language that provides an API sandbox (I think Lua can be used for this?) which provides enough functionality for game logic or mods, but doesn't allow open access to the file system, creating other processes, etc.

You could also sandbox the whole game (with an OS-level process privilege sandbox, such as by developing it as a modern Windows "app" or using the MacOS sandbox), with a special location (readable by the sandbox) where the user can drop mods, etc. That way, even if the game gets compromised by a malicious mod or similar, it cannot impact the OS much (if at all), although it could still attack the game and anything it has access to. Games generally don't need a lot of OS permissions - maybe network connectivity, somewhere to put save files, all stuff that the OS-provided sandboxes handle easily - and are actually kind of an ideal use case for these app sandboxes.

Generically speaking, the term you're looking for is "sandboxing" (as in, a place this kiddies can make a mess without affecting anything else). Sandboxing is a kind of hard problem but it's also very useful, so there are a few different places it's commonly used.

For example, all modern web browsers have not just one but two layers of sandbox. The old one is the JavaScript sandbox: people run untrusted JS code on their machine all the time, usually safely. This is implemented as an API sandbox; the JS that you can run on a browser simply has no functions you can call, and no way to define functions, that do particularly malicious things (like read or write arbitrary files, open arbitrary network connections, etc; everything is safe, restricted to a safe subset, or unavailable). However, JS is complicated and JS runtimes are prone to security bugs, so modern browsers additionally run their rendering and JS engine in a sandbox too. This second sandbox is implemented as a process privilege sandbox; the browser process that creates the window and such spins up a bunch of child processes, each with extremely restricted permissions, and uses them to process all untrusted code, communicating with them through very carefully secured and minimal inter-process communication channels. That way, even if malicious script finds a way out of the API sandbox and can call arbitrary C functions, most of the interesting ones (like file reads) will fail because the OS says the process doesn't have permission to do that.

Process-based sandboxes are pretty common these days, and all modern OSes have [at least some] support for them. The Windows, Mac, iOS, and Android app stores all provide sandboxed apps. Linux provides sandboxing functionality that is used by things like Docker (and Chrome on Linux). FreeBSD (and derivatives) have "Jails", etc. There's a bunch of ways to do it. A relatively-simple one can be created just using user permissions and ACLs; you create a new user account for the sandbox, give it access to nothing at all by default (which is tricky, since normally there's a lot of stuff that's world-readable, at least), and then grant that user account access to the things the sandboxed code is allowed to touch. A process launched as that user will have very limited access to the system, until/unless they find a way out.

Unfortunately, creating a secure sandbox tends to be somewhat platform-specific, and tricky for each individual platform. I've personally reviewed, and found breaches for, sandboxes used by multiple Big Software Companies' products (you've heard of them, might even have them open right now). The app store sandboxes model - which give the developer fairly little control over what can be done, in exchange for the OS handling all the sandbox creation and enforcement - is appealing and if you're writing for Mac or recent Windows I recommend considering it.

Another kind of sandbox, available on any modern desktop OS but pretty expensive to run, is a virtual machine (VM) sandbox. Using any major VM platform (VMWare, VirtualBox, Hyper-V, whatever), you can create a VM that has little or no access to the host OS. This is the standard way cloud computing providers work; from Amazon's perspective your tiny EC2 instance is running untrusted code, yet has to share hardware with other mutually-untrusted users to be cost-effective, and VMs are used to do this. It's also a way to run potentially-malicious code, because the host OS can watch what the VM does but the VM cannot control the host.


If I visit a https site from a Family Safety-enabled computer, and someone drops in on the connection, will I be notified?

I played around with Family Safety on Windows 8.1, and from what I can tell, it's seems to be smart enough to check the validity of the original certificate before it proceeds to replace it with a Microsoft certificate.

From the screenshot below, you can tell that when I visited Google, Google's real certificate was replaced by the Microsoft Family Safety certificate:

However, if I visit a site with an invalid certificate, it still presents a warning:

So it is pretty clear that if the certificate check fails, Family Safety will NOT replace the certificate and will instead allow the warning to be shown. I tested this in both Internet Explorer and Google Chrome and both display the same behavior.

  Furthermore, to re-encrypt, Family Safety would need to have the
  private key for the cert on my personal computer, and on six billion
  other personal computers, and IE trusts that cert. So a malicious user
  could use this private key and his servers would be certified
  Microsoft servers and trusted by IE by default. Correct?

The family safety certificate isn't being used for website verification, so there's no need to install the same one on every computer in the world. I'd imagine that it is randomly generated and added as trusted when you enable Family Safety (or at least when the computer is installed). Theoretically if someone steals the key for the certificate on YOUR particular computer, the might be able to man-in-the-middle YOU without generating warnings, but no one else.


Can I find out if my employer is snooping on me?

The short answer is yes, technically speaking. They will have another admin account on the computer that they can access. By policy, though, access to this account is (hopefully) tightly controlled and will only be accessed if necessary.

Also, there is no such thing as your computer legally speaking if it is a work issued asset. They can look at anything at anytime for the most part with little or no justification needed. It's theirs and so is all of the data you put on it.


Is it feasible to recover a zip file password consisting of about 16 digits?

the password were chosen randomly, by randomly hitting keys

TL;DR: Feasible to crack if the archive was protected with ZipCrypto, not feasible if the archive was protected with "WinZip" AES encryption.

16 of random digits = 10^16 = 10 000 000 000 000 000 of combinations = 53 bits

It means that, for instance, if you're able to achieve a password verification speed of 100 000 hashes/sec, it will take the following amount of time to brute force the password:

100000000000 seconds
1666666667 minutes
27777778 hours
1157407 days
3171 years

More things to consider (thank you, comment section!):

1000 000 hashes/sec => 317 years of brute force
10 000 000 hashes/sec => 32 years of brute force (depending on particular WinZip/7-Zip/PKZIP algorithm using GPU (see benchmarks for Nvidia RTX 2080)).
30 GH/sec => 4 days (I can see some hashcat measurements about PKZIP in the same benchmarks)
22.7 ZettaHash/sec => a second of brute force. Seems like that is feasible for original PKZIP encryption algorithm which could be brute forced using some specific attack with the speed of "22.7 ZettaHash/sec on a single RTX 2080Ti". You can crack 16 numbers in seconds then. Not AES+PBKDF2 yet which is used in WinZip.

At least two different algorithms are widely used to protect zip archive:

ZipCrypto (PKZIP encryption)

Original PKZIP encryption is absolutely weak (it uses CRC32-based key derivation): from 10 MH/sec to 30-100 GH/sec and up to 22.7 ZettaHash/s on 1GPU. You can crack 16 numbers from seconds to 1-2 days feasibility depending on specific attack, hardware and optimization set. If you're not lucky enough than it would be years still.

AES encryption (WnZip encryption)

WinZip uses AES-based encryption with PBKDF2-HMAC-SHA1 1000 iterations key derivation: 5 MegaHash/s on 1GPU. And this is 32 years.


When would you support the storage of Security & Application event logs in the Cloud?

If the requirement is purely storage (no active analysis required), then it would seem sensible to encrypt the data using GPG/PGP or similar before sending to the offsite facility.

At that point from a security standpoint the primary issues are availability of the data to be accessed when required, so it'd be important for the provider to be able to prove that they take appropriate measures (backup, redundancy, DR/BCP, etc) to ensure that the data is available if needed.

If the idea is that the data will be processed at the 3rd party site and therefore needs to be processed in the clear, then the risks change substantially as there's a confidentiality/integrity risk as well.

So then it'd likely depend on what's in the logs, as there might be regulatory requirements for processing the information (eg, EU Data Protection Act), and the supplier would need to provide strong evidence that their security controls are at the same level or higher than the customer to ensure that the log data is appropriately managed.


Does anti-CSRF token really protect from CSRF?

CSRF tokens are unique for each user and stored on either the server or client side. This means an attacker would have to guess the value of your CSRF token to attack you. If the token is generated using a cryptographically secure PRNG, a basic attack like you describe is not possible.


Protecting a web app from unwanted vulnerability scanners

Is there a method i can use to protect my web application from such unwanted scans to my web application?

You can protect your web application by:

using secure coding practices,
diligently patching software,
implementing a Web Application Firewall,
regular approved scanning of the type offered by these 'security experts' (and remediation of their findings),
Application Security Testing,
(not an exhaustive list.)

Note that in these cases you'll still get scanned - both by these 'security experts', who are contacting you after the fact, and by the 'hackers', who you don't know about because they haven't contacted you.

As long as your application is on the Internet, it'll get scanned.  Constantly.


How do you check the signature of a signing program (ex. GnuPG) if there is no native version installed? [Catch 22]

Your question boils down to "how can I initially construct a trust chain". No matter how you want to verify the download or individual steps (for example, X.509 certificates for HTTPs), you will have to start trusting somewhere.

The most paranoid method of verification would be meeting GnuPG's main author, Werner Koch (and/or others from the core team). But as you don't know him yet, consider how to verify his identity (for sure, a powerful governmental organization would be able to issue faked ID cards).

Otherwise, you could start with trusting your operating system distribution for downloading and verifying GnuPG. Maybe you're even running Linux for a long time, and fetched copies from lots of different locations. This is "trust on first use" in the broader sense: you expect that the first contact (older copies of Linux) have been fine before you even might be considered a target worth the vast effort of such manipulations.

If you don't trust a single copy (as it might be manipulated), go for multiple of them, repeating the step individually. You will find Linux distribution media "kind of everywhere": computer magazines in stores, as add-on to library books, by asking your friends. It is very unlikely that an attacker was able to fiddle with all of them. Whenever somebody enlarges the scope of manipulations, chances of getting caught increase.


Security fields: AppSec vs. InfoSec vs. NetSec, etc

Two points to consider: these are all relatively loose terms, and practitioners often have to be able to function in the roles of regular admins or programmers to be functional. That does not mean they have to be as efficient -- AppSec folks probably aren't as used to writing sorting algorithms, for example.

Information Security

Umbrella covering everything to do with information security. InfoSec specialists cover a wide range of topics and are skilled generalists. In a big company setup, they are your CISOs and managers. In a smaller company, they are your practitioners.

Application Security

Related more to software design and programming. AppSec specialists are familiar with programming and tend to focus on secure application design.

Network Security

Firewalls, IDS, VPNs; practitioners understand lots of application-specific protocols. Anything that flows through a router is in their world.

IT Security

Host-based security, domain controllers / auth servers, mandatory access controls systems. ITSec is focused inside of the system.


What triggers a firewall to block a TCP socket?

There are two main types of firewalls.  The first type is the network kind where it simply blocks a port in general.  It does this by simply not allowing a connection on that port, typically unless an outgoing connection is made on the port first.  The other is an application firewall which runs on a client and restricts which applications specifically can access the network or be accessed by the network.

A firewall is going to block a particular TCP port simply because that is how it is configured.  There isn't anything that "triggers" it.  It's just the behavior of the device to not allow connections that aren't configured.

If it is an intrusion detection system rather than a simple firewall, there could be traffic analysis done on the data being exchanged and if suspicious activity is detected, then it could be configured to start blocking the port, but that's a more rare situation.  If this covers your situation, you'd have to talk to the people that configured the IDS rules to know what caused the blocking.


Publishing the public key on an HTTPS website is fine, and pretty common. However, it does introduce a security dependency between the website and the payloads. If the website goes down, payloads can't be verified. If the website is compromised, then the attacker could publish their own key on the site and send spoofed payloads that successfully pass signature validation.
Other options include:

Publishing the public key as a DNS TXT record, with DNSSEC. Less attack surface than a website, but still creates a new security dependency. Means security of your payload signing key depends on security of your DNS registrar account. Clients must validate the DNSSEC signature or else an attacker can use a DNS spoofing attack to spoof the payload public key.
Using the public key in your TLS certificate (which is signed by a CA as belonging to you). Certificates are often harder for attackers to tamper with than website content, and an attacker can't replace the cert with their own unless they get a CA to issue one fraudulently. Means the cert and the payload signing key rotate together, but this shouldn't be a problem unless you either rotate the signing keys very frequently. Certs can be re-issued, potentially with new keys, on a pretty frequent basis (indeed, some CAs only issue short-lived certs).
Combination of the above: frequently-rotated public key on your website and/or DNS record, but itself signed by your TLS public key. This prevents an attacker from modifying the payload signing key without also compromising your TLS private key or replacing your TLS certificate, but allows you to rotate the TLS key and payload key independently (though you'll need to promptly update the payload key signature whenever you rotate the TLS key).
Giving each client the current and future keys through some authenticated method (such as a download from a TLS-protected website), with scheduled rotations, and periodically supplying more keys as the old ones rotate out. Requires that the client have secure and persistent data storage for the keys and potentially complicates onboarding new clients (if you can't just embed the keys in an app bundle or something) and handling unscheduled rotations. A compromise of the authenticated distribution channel may result in some clients having compromised keys with a long duration, which could complicate incident response.
Giving each client their own keys (typically a primary and a backup). This reduces the exposure of any individual key (if your concern is that the public key might be cracked), but is otherwise probably just a higher-cost version of the above.

You might want to examine why you expect to rotate the key pair so often. Generally, this isn't needed; even relatively weak public keys should be good enough for years. Concerns such as replay attacks or known-vulnerable versions should be handled using timestamps, monotonically-increasing nonces, monotonically increasing version numbers, or so on, all of which would be signed as part of the payload.


Does VNC need hardening when inside LAN (home network)?

Even if the internal network seems to be under full control and the internal VNC or RDP services are not directly exposed to the internet, this does not mean that they cannot be accessed for sure by an attacker. Just by visiting a website controlled by an attacker the browser could be instrumented by this attacker to scan the local network, access internal services or even open arbitrary ports from the internet.
The latter was 2008 demonstrated with UPnP requests issued from a flash application and a few month ago with the most recent browsers at this time again, see NAT Slipstreaming. This way unsecured internal services could be made accessible from the internet.
Therefore internal services, including RDP and VNC should still be hardened, i.e. have latest patches and proper access control.


Is it possible to use the aircrack-ng tool to crack a WPA2 Enterprise network?

Not alone like a WPA/2 PSK attack, where you can simply capture the handshake and bruteforce.

You'll need to capture the "Enterprise" authentication attempt. To do this, you can perform an "Evil Twin" attack that captures the authentication attempt, which can then be subsequently cracked.

Here's an excellent presentation by Matt Neely of SecureState that details the attack: http://www.slideshare.net/NEOISF/attacking-and-securing-wpa-enterpris

Specific Steps of the Attack:

Attacker sets up a Fake AP

Mirror the target SSID, encryption type and band
Configure the AP to accept Enterprise authentication
Enable AP, ensure it is visible to the target

Connect the AP to a FreeRADIUS (with password Wireless Pwnage Edition patch) server that captures auth
Deauth any target you can get within range of your fake AP
Wait for targets to attach to the the fake AP, capture their authentication
Crack the challenge / response pair to recover the password

Hope this helps!


Size of initialisation vector and plaintext in CBC mode

In CBC mode, the IV is ALWAYS the same size as the block size used by your encryption algorythm.

Thus, if you use AES, your IV will have to be of exactly 128 bits, regardless of the size of the data you have to encrypt.

So, the proper way to encrypt your data in CBC mode is to:

Divide your data in blocks of the appropriate size (128 bits for AES) bits
If necessary, Add padding the last block to extend it to the block boundary.
Generate an IV of the same size as the block size used by the algorythm (128 bits for AES)
XOR your IV with the first block and apply your encryption algorythm to the result.
Take that first cyphertext block and XOR it with the second plaintext block.
Repeat.


Why improvising your own Hash function out of existing hash functions is so bad

The fact that you need to ask this question is the answer itself - you do not know what is wrong with stacking these primitives, and therefore cannot possibly know what benefits or weaknesses there are.

Let's do some analysis on each of the examples you gave:

md5(md5(salt) + bcrypt(password))

I can see a few issues here. The first is that you're MD5'ing the salt. What benefit does this give? None. It adds complexity, and the salt is simply meant to be unique to prevent password collisions and pre-computation (e.g. rainbow table) attacks. Using MD5 here doesn't make any sense, and might actually weaken the scheme since MD5 has known trivial collisions. As such, there is a small possibility that introducing MD5 here might mean that two unique salts produce the same MD5 hash, resulting in an effectively duplicated salt. That's bad.

Next, you use bcrypt on the password. Ok. Well, most bcrypt implementations require a salt internally, so this is already technically invalid. Let's say you know that, and you meant to say bcrypt(md5(salt), password). This part is still falling to the weakness I described above, but it's not too shabby - remove the MD5 and it's a standard use of bcrypt.

Finally, you MD5 the whole thing. Why are you doing this? What is the purpose? What benefit does it bring? As far as I can see, there is no benefit at all. On the detriment side, it adds more complexity. Since most bcrypt implementations use the $2a$rounds$salt$hash notation, you're going to have to write code to parse that so that you can extract the hash part and store the rest separately. You're also going to need an MD5 implementation, which was unnecessary.

So, in terms of code footprint for potential attack vectors, you've gone from a simple bcrypt implementation, to a bcrypt implementation with custom parsing code, and MD5 implementation, and some glue code to stick it all together. For zero benefit, and a potential vulnerability in salt handling.

Next one:

scrypt(bcrypt(password + salt))

This one isn't too bad, but again you need some code to parse out the results of bcrypt into hash and salt / round count separately. In this case I'd guess that there is a slight benefit, because bcrypt and scrypt work in different ways for roughly the same goal, which would make it a little more difficult for an extremely well-funded attacker to build custom ASICs to break your scheme. But is that really necessary? Are you really going to hit a situation where a nation state will devote a few million dollars to just to break your hash? And, if that case ever arises, will it really bother the attacker to have to spend a few extra million to double their chip count?

Another potential issue with combining bcrypt and scrypt like this is that there has been very little study into how the two interact. As such, we don't know if there are any weird cases that can cause problems. As a more obvious example, take the one time pad. We compute c=m^k for some message m and some equally long perfectly random key k, and we get perfect security. So let's do it twice, for even more security! That gives us c=m^k^k... oh, wait, that just gives us m. So because we didn't take the time to properly understand how the internals of the system worked, we ended up with a real security vulnerability. Obviously it's more complicated in the case of KDFs, but the same principle applies.

And finally:

sha1(md5(scrypt(password + md5(salt))))

Again we're running into the MD5'ed salt issue. I'm also intrigued by MD5'ing the SHA1 hash. What possible benefit could that have, if you're already using a slow KDF like scrypt? The few nanoseconds it would take to compute those hashes pales in comparison to the hundreds of milliseconds it would take to compute the scrypt digest of the password. You're adding complexity for an absolutely irrelevant layer of "security", which is always a bad thing. Every line of code that you write is a potential vulnerability.

Now remember that point I made at the start of my answer. If, at any point in this answer, you thought "oh yeah, I didn't think about that", then my point is proven.

You're running into what I would describe as Dave's false maxim:

  If I add more crypto things, it will be more secure.

This is a common trait among developers, and I once believed it too. It goes hand-in-hand with denial of other principles, such as Kerckhoff's Principle. Ultimately, you have to realise and accept that obscurity isn't a safety rail; it's a crutch for weak crypto. If your crypto is strong, it needs no crutch.


Snaplytics says that they encrypt the password, not hash it.  When data is encrypted, it can be decrypted back to the original plaintext with the use of a key, which Snaplytics hopefully keeps secure internally.  In this way, the passwords are not stored in plaintext and are difficult to retrieve if Snaplytics' database is compromised, but when Snaplytics needs to log in to a user's account they can retrieve the plaintext password just long enough to authenticate with Snapchat.  I took a cursory look over their site and don't see any information about what specific encryption they are using.

You are correct that when you are running a service which uses password authentication, you should hash passwords before storing them in the database because you do not need the actual plaintext password.  However, Snaplytics has to transmit the password to Snapchat in plain text so Snapchat can (hopefully) hash it on their end and use it for authentication, so Snaplytics does not have the option of storing it via a one-way hash.


How to decrypt TLS in WireShark if I can hook the application's crypto API calls?

There is no way to let Wireshark work directly on the application level data you've got. But you can create a new pcap based on these data and then use Wireshark to analyze this pcap. For example this can be done with a bit of Perl and the Net::PcapWriter module which lets you easily create a pcap and add TCP connections with your own application data to it:

use strict;
use Net::PcapWriter;
my $pcap = Net::PcapWriter->new('test.pcap');
my $conn = $pcap->tcp_conn('1.1.1.1',1234,'2.2.2.2',80);
$conn->write(0,"GET / HTTP/1.0\r\nHost:..."); # HTTP request from client
$conn->write(1,"HTTP/1.1 200 ok\r\n...");     # HTTP response from server

Similar things can probably done with Python and the famous scapy library.


Why does ACME / Let's Encrypt require A records not CNAME?

The answer by sebastian nielsen is wrong insofar that the security hole was in an unrelated service called startencrypt. The implication that Letsencrypt doesn't support CNAME records is also incorrect as verified by this thread and several others where Letsencrypt moderators assure people that they do support CNAME records. In fact I have just passed verification for a subdomain that I have pointed at an Azure VM by using a CNAME record.

The error message certbot gives, when something is wrong is pretty misleading though and I could not find anything in the official docs about CNAME support, leading to all this confusion.


I have red that all passwords should be random. This is ideal but not feasible.

Why not?

  1)It is most difficult to remember and password managers may not be a viable option (for example password to memory stick you carry with you).

Why isn't it feasible? I do it all the time.

  2)It has been stated that computers should not be used to create random passwords.

Where is this stated? This is blatantly false.

  3)Some devices it's very hard to type long complex passwords in, such as smartphones.

Smartphones have password manager apps as well. They allow you to copy and paste passwords stored in them.


Is there a tool that reports on PKI health (CRL dates, expiry, etc)?

Just to add my one cent.

I'm not aware of any such ready tools, however this feature was requested by a customer of mine some time ago. Eventually, I ended up with my own PowerShell solution for Windows. Here are two blog posts where I describe the behavior:

Enterprise PKI (pkiview.msc) PowerShell Edition (PoC)
Enterprise PKI health verifier, PowerShell Edition v1.5

Although, postings refer to Microsoft ADCS, there is a -Certificate parameter where you can pass arbitrary certificate.

Generally, the script does the following:

Prepare input certificate;
Execute chain for each certificate to select trusted anchors and to go through the chain;
Retrieve all Issuer URLs from AIA;
Validate each url (must be either http or ldap) and attempt to download the contents;
If contents is downloaded, verify whether it is a certificate;
Verify if the downloaded certificate is an issuer of the certificate in subject;
Validate other cert properties;
Extract URLs from CDP extension;
Validate each url (must be either http or ldap) and attempt to download the contents;
If contents is downloaded, verify whether it is a CRL;
Validate basic CRL properties, like validity (not yet valid, expired, about to expire);
Validate whether the CRL has valid signature (against CA certificate);
Do the same for DeltaCRLs;
Extract all OCSP URLs from AIA extension;
Validate OCSP response by sending OCSP request and processing response;
Compose status report (managed, I maintain report object and you can access report properties);
Repeat steps 3-16 for each subsequent certificate in the chain up to root certificate;
Compose summary report.

Not all you've requested (cross-certificates are not verified), but enough for a good start.

Where to get the latest version of the script? It is a part of my PowerShell PKI module. Download sources of the most recent release: https://pspki.codeplex.com/releases

you will need only three files:

Get-EnterprisePKIHealthStatus.ps1
PKI.Core.dll
SysadminsLV.Asn1Parser.dll

All files are digitally signed by me. If you concern about dlls, they are opensourced: PKIX.NET (PKI.Core.dll) and Asn1DerParser.NET (SysadminsLV.Asn1Parser.dll)

and the last, online help for PowerShell function: Get-EnterprisePKIHealthStatus.

HTH


How to reliably backup to cloud services without hampering security?

If your concern is avoiding losing all of your physical assets (laptop, phone, etc...) you could simply encrypt your files using any software you like and then upload redundant copies to two or more storage services which you think are the most stable and secure. That said naturally you would want to choose a great encryption algorithm and use a strong password that would be very hard to break. This could be done easily with PGP, TrueCrypt, or VeraCrypt but there are also plenty of other options. A simple SFTP server on a cloud compute platform like AWS would work well for what it sounds like you need.


Reporting this to local law enforcement sound like the right thing to do. Hopefully they will have access to people who are competent enough to make use of the information you can provide without you getting into trouble.

You should also contact whoever you are using for processing credit card transactions. Ideally they have an API that you can use to report suspected abuse while preserving the same security for the card number as a normal transaction.

Your own logs will obviously contain IP address and time of each abuse attempt. But I would refrain from logging the card numbers, as you could potentially get into trouble yourself, if you did.


How are full URLs exposed when they are encrypted by HTTPS?

The article states that:

  a connection was discovered to a web filter app built by Conor [Solutions]

Given that it was a web filter, and given that it was able to log URLs, we can infer that this was a Man-in-the-Middle (MITM) proxy which decrypted the requests, filtered based on the unencrypted request, and then re-encrypted and forwarded the request to the actual destination.  And unfortunately, it logged these requests, and that log got compromised, thus the leak.

This sort of MITM would require a CA certificate be installed on the client so that the proxy could present certificates for each web site visited.  Presumably Conor Solutions had some way to roll this change out to customers; perhaps there was "filtering software" for customers opting into having web filtering as a package.


side channel attack vs eavesdropping attack

Yes.

Eavesdropping means that someone (usually someone named Eve...) eavesdrops on Alice's communication with Bob. Eavesdropping can break the security of a system, for example when the protocol has passwords transmitted in plaintext.

A sidechannel attack takes advantage of information leaked via (insert drums here) a side channel which you watch to break a system. Sidechannel attacks don't need to involve any eavesdropping on actual communications between Alice and Bob; the attacker might just attack the system directly and observe a given side channel.

For example, here's a simple side-channel attack against naive implementations of a password check that uses a for loop to check each secret character against a provided password:

def check_password(provided):
   secret = 'open-sesame'
   for i in range(len(secret):
       if provided[i] != secret[i]:
           return False
   return True

(The above python code wouldn't work in real life, but bear with me): If you use such a check, it takes less time when the first character is wrong than it takes when the first character is right, because the for loop will be terminated in the first iteration. So you can simply try a password starting with A, then with B, then with C and so on and measure the time it takes for it to be rejected by check_password. When it takes a bit longer, you know you have the right first character. Now repeat that with the second character, etc.

The communication going on here is that you're providing the check_password function with a password and get a True or False (accepted or rejected) answer. The time it takes for the password to be accepted or rejected is the side channel, and since the time isn't the same for accepted and rejected passwords, the system leaks information over this side channel, which can be exploited to turn password guessing into a O(n) operation, where n is the length of the password in characters.

You might think such tiny differences in timing can't be exploited, but it's been shown that such timing attacks even work remotely (e.g. by measuring how long it takes the server to reply with a "access denied" message), provided that you collect enough statistical information about how long the average answer takes to reach you.

https://www.sjoerdlangkemper.nl/2016/11/01/tenex-password-bug/ describes an older timing attack against password checking found on the tenex operating system which exploited timing differences introduced by the paging infrastructure . That one's pretty famous and the provided link has a nice and detailed explanation.

Timing attacks are just one example of side-channel attacks. Another side-channel is power consumption, and recently Bruce Schneider blogged about a research paper that used an attack using wifi radiation patterns to determine your smart phone password. Also see news article about it.


What are the career paths in the (illegal) computer security field?

My 2cents here: While not technically illegal these companies have managed to develop malware and exploits, without anyone bugging them, because they sell them to governments, law enforcement agencies, secret services, organizations and, in case of some of the companies, to anyone else interested.

Such companies include:

VUpen
Paladion

More information can be found: here.


It's not that simple. You need to learn about fuzzing and debugging. There's no magic scanner that can find vulnerabilities. A good tool for fuzzing is Peach Fuzzer, but if you don't know about debugging, assembly, cpu registers, etc... you won't get very far.
A good book to get you started is "Hacking The Art of Exploitation"


Why is it easy to detect network layer DDoS attacks?

Network-layer DDoS attacks typically involve a lot of very similar traffic; it follows a discernable pattern, it appears in statistically unusual quantities, and it looks very different from the surrounding "normal" traffic.

That's what makes it easy to identify.


Use of rainbow tables with the NY Times hack?

This is mostly speculation, but I see a number of plausible scenarios:

The article is correct, and NY Times did not salt their passwords;
They salted them, but used a hashing algorithm not slow enough;
The attackers targeted a few specific passwords (probably by guessing and/or brute forcing them).

As for your last question, AFAIK the value of salting is to increase the amortized cost of breaking N passwords (i.e. without salting, breaking 1 password or all of them have the same cost; with salting, N passwords cost N times more than 1 password). A rainbow table could be created specifically to target a single account, but the cost of doing so is always greater than just brute forcing it (see @ThomasPornin's comment), so I doubt that's what happened. So I'm guessing you're right in your suspicion that "the reporter was confused about how the hack would likely have occurred".


Remote and local file access don't mix. Remote sites should know absolutely nothing of what's on your hard drive, except what's carefully exposed in controlled ways, such as HTML5 local storage and cookies.

Anything that gets loaded into the DOM can be examined by scripting, which means that allowing file:/// inclusion would effectively give any remote site read access to all the files on your computer. Malicious sites could then levarage this hole to covertly steal secrets from you, which could then possibly lead to further exploitation.


2-factor authentication everywhere: is this possible?

For apps, you would need a custom ROM on the device to prompt for this. But the risk/reward balance is a little off for devices.
There are services that can be used to add MFA to online services for a single-sign-on account, but that adds it for that 3rd party account, not the individual services account.
You cannot add MFA to something that isn't expecting it. It's like trying to add another password. If the service isn't expecting it, then who checks it to verify it passed? Who blocks access if it fails?


How wireshark capture packets in LAN without arpspoof?

This is actually not a security question at all. The question you want to be asking is how one node on a network can see the packets that are not destined for it. For this answer, you need to understand how Ethernet networking works.

Ethernet networks are broadcast networks, meaning that every node on the same segment can see every other node's traffic. No tricks required.

A switch, and a wifi access point acts like a switch, breaks up these broadcast zones (mostly) so that only the nodes that need to talk to each other see the traffic. That's why you need to arp-spoof: you need to trick the victim node to send you the traffic first and then you pass it on to the intended destination.

But without a switch, everyone can see everyone's traffic. So, your Kali's Wireshark could simply and easily see the traffic being sent by the other node. No tricks required.


The document you linked to details how the author bypassed pinned certificate validation in two different ways : by disassembling the application, removing the check and rebuilding the APK or by changing the certificate in the application keystore. Both method require a high degree of access to the application.

There are no way to fully protect your application against this. That is one of the reason why you should never trust the client.

However, these attacks requires the attacker to be able to replace your application with the modified version. If the attacker is the owner of the device, you simply cannot prevent it. Otherwise, the best you can do is rely on the OS security and warn your users not to root their devices.


Getting multiple key matches on plaintext/ciphertext pairs in double DES

For a cipher each key defines a different permutation, but that doesn't mean that there cannot be identical 1:1 relations. Take AES-256, which maps 2^128 values to another 2^128 values using a 256 bit key and you encrypt one 16 byte plaintext, say all zero's. The output will also have 2^128 values. So there must be keys that map the same plaintext to the same ciphertext.

That's probably not what's biting you though. DES keys have parity bits, which is the lower bit in each byte. This bit makes sure that the number of bits in the byte is always odd. An implementation may chose to ignore the parity bit. If you have a key that only differs with regards to parity then the key value used to derive the sub-keys is identical. So only the topmost 7 bits of each byte matters, giving DES an effective bit size of 64 - 8 = 56 bits.


Application is validating the file extension but not file content - Is this a security vulnerability?

It is unclear what the expectations on the application are in this case and thus your question can not be answered.
For example if the recipient expects data from untrusted sources anyway, it can be expected that the PDF is checked at the recipient. If the recipient instead expects fully trustable data, then more checks need to be done on the way to the recipient. These might be done in the web application during upload but also might be done at a later stage during delivery.
In other words: you cannot have a look at the application in isolation but must see the bigger picture. From that you can derive the requirements on the application. Only with the actual requirements you can decide if this is a vulnerability in the application or not. And only with the bigger picture it can be determined if and how such a vulnerability could actually be exploited.


Why did the Papal conclave use a Faraday cage in 2013 when selecting the new pope?

When you read up on the source quoted in the article, you will notice that it apparently isn't talking about a "real" Farraday cage around the Sistine Chapel (putting a whole building under a wiremesh dome would be ridiculous even for the Catholic church) but rather about a figurative one in form of:

  the installation of equipment which blocks any electronic signals from getting out of the Sistine Chapel.

The author doesn't seem to be very tech-literate (see second to last paragraph), but it appears like he is talking about GSM jammers or similar devices which make cellphone communication impossible though active interference, not passive blocking. Such device are available commercially over the shelf for affordable prices. By the way: such devices violate broadcasting regulations in many countries making them illegal. But the Vatican is a sovereign state, so they don't have that problem.

The main motivation for this measure was that during the last conclave in 2005, the election of Pope Benedict XVI was leaked to the media before the official announcement. This is what the Catholic church wanted to prevent from happening again in 2013 and this is why they took technological measures to prevent anyone inside the conclave from communicating with the outside world until the official announcement.

Leaking information later was a secondary concern.


I've tried that tool, and it's fairly good and secure. I have also tried to recover data (using professional software) after using eraser and nothing. It's not good as Blancoo or BCWipe, but it is sufficient.
Non-free tools have also verification of wiping process. Also I'm not sure if eraser will consider removing HPA and DCO.


Are reproducible builds practically possible on major app stores?

The answer is no, and that's because most major app stores require signing and generally the signature process used includes a timestamp.  Timestamps are inherently non-reproducible.  This is the case for both phone app stores and computer app stores.
If you wanted to ignore signatures, it probably is possible.  Debian does it, and many pieces of software used during builds are probably already patched upstream by now.  It may require a post-processing step for certain files, though, which most developers will not implement.  So it is not reasonable to expect that anyone but the most security-conscious developers will implement it.  For example, Signal does it for Android, but most developers do not.


Can you sniff packets from a router using wireshark?

Packets designated for the router will not propagate through the LAN network, at least not from the WAN side. All packets from inside the network will be available to other device as well, when put into promiscuous mode. A switch, which acts on MAC addresses, not on broadcast domains (thats a hub) can cause trouble indeed.


OpenVas now has the ability to import Nmap scan results in .xml format, which to me, is great. I like performing nmap scans outside of a vulnerability scanner because not only can I have greater control over some parameters such as "--top-ports" etc, but I re-use the results often (e.g. metasploit import) and prefer having them as "standalone files" for that reason.

To import them using Greenbone Assistant: select your scan configuration >> edit port scanners >> edit Nmap >>  import results file >> save.