Signing webhooks: symmetric vs asymmetric

I suspect there's 2 reasons for this, preventing replay attacks, and key rotation.

With Github for example, it signs the message payload using HMAC-SHA256, and then places the signature on a header value, which can be verified by the hook endpoint.

A replay attack is simple enough, I generate a few webhook calls to my API, and since they're all signed by the same key, I can take those same payloads and use them to call your webhook, and it will at least pass the first authentication step.

You could check certain fields in the payload (e.g. the repositories full name) to ensure these are really 'your' webhook calls, but message types can be different depending on the event -- it's much easier to authenticate the message by checking one signature that's always found in a known HTTP-header, then it is to parse different message formats trying to extract these fields. More importantly, it's always a good idea to authenticate first and then process the message, authentication of a message based on a public key isn't really 'authentication' in this case, as I could easily impersonate it.

The second reason is key rotation, having just one key for ALL Github webhooks is a phenomenally bad idea! Should that key get compromised, an attacker could impersonate GitHub on any Webhook.

Worse yet, imagine if 5 years from now, GitHub wants to swap the public key -- now every GitHub webhook needs to change in a co-ordinated fashion, not easy when you have millions of webhooks. By having user-defined keys, Github has pushed the key rotation maintenance onto the users (as they should), and let the user define their own key rotation policy (which could be never!).


Is there any problem associated with using emojis in WIFI SSID?

The only reason it might be a security issue is if there's some WiFi software that incorrectly expects the SSID to be ASCII text or similar, in violation of the specification. Such buggy software could potentially face a memory corruption vulnerability while mis-processing the SSID, though the far more likely outcome would simply be that the station can't connect (or, if the bug is in the AP, that nobody can connect). Since APs need to be able to handle arbitrary connection requests and stations need to be able to handle arbitrary SSIDs from scans, any such vuln is either attackable by any user in range, or only reachable from the admin interface of your router; in the first case you're not putting yourself at risk (though you might identify some buggy systems), and in the second case... it's your hardware, if you want to risk making it malfunction, have fun.
The specification requires only that the SSID be no more than 32 octets (bytes); as https://stackoverflow.com/questions/4919889/is-there-a-standard-that-defines-what-is-a-valid-ssid-and-password points out, 32 null bytes is a valid SSID. That's potentially not very many emoji, since some are more than four bytes per character, but it's room for a few. Note that the standard does not specify how SSIDs are to be encoded, so if they don't expect UTF-8 (or whatever other encoding you use) then your SSID may not display correctly (probably just as boxes for unknown characters, but possibly as weird incorrect ones), but that's not a security risk per se.


How can I stop someone from displaying my website on his domain?

The answer depends on the web-server you are using. For example, apache allows for the creation of multiple virtual hosts, of which the first described is considered the default one.

What I suggest to do, is to create this default "catch-all" virtual-host with a global deny rule on it. Then configure your own web-site with a virtual-host identified with your domain name.

Therefore, any request coming in with a domain not matching your shall be denied access (404 I suppose).

An other thing you could do is get the "whois" information on said domain, ISP usually list in the records an email address to report abuse. Collect some information from your logs and ask the provider to terminate this.


I'm going to quote this post from SecLists.org

  Those alerts are supposed to fire when an SSL Client Hello is seen in
  a session, but the SSL preprocessor already saw both a Client Hello
  and a Server Hello. The alerts were added to the preprocessor as part
  of Snort 2.9.0.

The best thing I've seen to do is suppress the specific alerts. This tutorial on Youtube is quite informative on how to do so.


Protecting encrypted data in case of SQL injection

If I understand your question correctly, your system uses the same key to encrypt and decrypt the message for both patient and doctor.

In which case your attack is theoretically possible assuming you could read another user's message and insert it into the DB as your own message.

Mitigation in terms of encryption against this would be a unique key per user or using public/private key pairs to encrypt the data with each user again having a unique key for additional security and limitation of damage in the event of a breach.

Other mechanisms would include appropriate defence against SQL injection by sanitising input and also a user verification system to ensure any registering user is a legitimate patient, this reduces the  pool of attackers but shouldn't be relied on alone.


What could happen if someone guessed a password to my FTP server?

There are a lot of attacks that can happen if someone gets access to your FTP server.

1) Wipe out your data stored on the FTP server.

2) Steal your data stored on the FTP server.

3) Exploit any of a variety of vulnerabilities to compromise your server.

4) Upload malicious content in hopes that you'll execute it.

5) Replace existing content with similar but malicious content (index.html becomes a webpage selling kiddie porn or something) that you or your other software will execute.

Typically, all software has bugs. Some of those bugs are publicly known of. An attacker can use known and unknown bugs to compromise your system, and it is far easier when they have login access, especially administrative access to a system.


Attack vectors with encrypted SAML assertion response

Either the SAML response or SAML assertion should be signed and the signature verified.

An XML signature permits the identity of the sender to be confirmed and any changes to the signed XML to be detected. This ensures the integrity of the XML.

Otherwise, the SP has no way of knowing who sent the SAML response or assertion and whether it's been altered after signing.

In your scenario it's possible that the encrypted assertion is signed and the SP is verifying the assertion's signature. However, it's unusual for both the SAML response and assertion to be signed so I would question whether the assertion is actually signed.

Encrypting the SAML assertion ensures privacy but anyone with access to the SP's public key can create and encrypt an assertion.


Windows Privilege Escalation system shell dies quickly

If I'm reading this correctly, you changed a windows service, UPNPHost, to use a different executable than it shipped with, right? If so, the process dies because it doesn't respond correctly to the task host, so it gets killed by the system.

  Ive tried adding another user as admin but do not know how to switch to that user.

You can switch using Remote Desktop. Anything that gets spawned by nc.exe will likely be killed immediately alongside it.

I presume this is how you added the new user as admin?

net user anderson cooper /add && net localgroup administrators anderson /add

Method 1: Remote Desktop

Try to RDP into the machine with the username anderson, and the password cooper. If RDP is not open, enable it:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Method 2: Meterpreter Migration

Alternatively, you can upload a meterpreter shell and use that instead of plain nc, and then quickly migrate to another process so the shell continues to operate.


You wouldn't get a list of all the passwords.  Any company that could or would produce such a thing would fail any reasonable security audit.

You might get a list of all the password hashes which could then be run through a tool that attempts to determine what the password is.  The ease with which the password hashes can be broken and the types of passwords that are broken will be a good guide to figuring out what password complexity policies need to be addressed.  If, for example, you're able to crack half of the password hashes because users are entering 6 character passwords that use all lower case letters, then you'd probably recommend increasing the minimum length and imposing some requirements about the use of uppercase letters, numbers, punctuation and other characters.


Is it safe to reuse a user's hashed password as his token in the email confirmation link?

You're right. I wouldn't do that. While mathematically, there isn't a way to reverse a hashed password, you could continually guess passwords and see what the resulting hash is. Where there's a match, bingo.

These offline brute force attacks are even more dangerous than online brute force attacks, because the speed at which guesses can be made is many orders of magnitude faster.

If it's a simple password, it would be trivial to obtain a hash rainbow table (common passwords and pre-computed hashes). Given a hash and a rainbow table, a password could be founds in seconds.

It would be far better to generate a random, long sequence of characters that could just as easily be copied and pasted. All this link needs to do is verify an email in a reasonable amount of time. Better to keep secret things secret when given the choice.

You might also include a timeout, so that if a user puts in a dummy email, whoever owns that email doesn't "verify" it a week later. Then a user could correct this dummy email to a valid email and request another link. Any subsequent request could void the first link's ability to verify an email.

Also consider adding a link in the email for folks to click if "I didn't create this account." That will keep your records cleaner and provide a method to flag garbage accounts for subsequent deletion after a set period of time.


Why is my Positive SSL certificate deemed insecure by Google Chrome?

Google blogged about flagging Certificates using SHA-1 here -> Gradually sunsetting SHA-1

There's no reason to get a new certificate yet as Chrome won't be actually blocking the certificate just treated as “secure, but with minor errors”, I believe that some issuers are offering to reissue certificate but as always, YMMV.


How can anyone access Intel's "backdoor OS", MINIX?

AMT is is hardly a secret. It is a feature for IT departments to get pseudo-console access to PCs over the network and remotely manage them.  (The common term is Out of Band or OOB management.)

It is comparable to HP’s iLO or Dell’s iDRAC, which are for servers. In the case of servers, there is usually a dedicated NIC for OOB. For desktops, that is not feasible. So Intel’s AMT lets the motherboard NIC be shared between the CPU and the Management Engine.

Here are some links to get you started:

https://software.intel.com/en-us/articles/getting-started-with-intel-active-management-technology-amt

https://www.howtogeek.com/56538/how-to-remotely-control-your-pc-even-when-it-crashes/

Note that despite many of the articles you read, not all Intel PCs have this feature. It is typically only found on business CPU/chipsets, as it is one of the differentiating features to justify the price point.


You should look into different SIEM solutions (If the company has necessary budget to integrate SIEM Solutions) & then see what risks are worth solving & prioritizing. If not, more traditional practices which is:

To determine the attack surface
Then determine the threats which could be possible to the organization
And then having a penetration test, a vulnerability assessment
Hence, defining what are the potential risks & if these risks mean any threat to your specific organization.

I suggest you go through these frameworks which handles risks in-depth:

  but one of the security guys introduced the idea to actually build our own internal platform/engine.

This might be possible if your company has prioritized what risks are most grave for them. In generic terms, one could use NIST as well. That's just an example. If the company is more into Application Security, I would suggest WASC or OWASP.

For OWASP, a Risk Rating Methodology does specify what risks are grave in nature (generically) which means these threats were to be solved in priority.


TXpower(transmission power) is the strength of the router's signal. If you are looking to reach a wider range, you configure the txpower to a higher setting in the router's settings.

One of the main concerns is security; a wider signal range is heard by more neighbors. If any of them is malicious and your router lacks proper encryption, you would be susceptible to malicious attacks. Hence why people suggest to leave the txpower at the default setting where it is only available to you; unless of course you have a viable reason to change it.


Where can I learn cryptography/cryptanalysis the hard way, without going to school ? Any good book?

(LZMA is a compression algorithm, not cryptographic.)

For the purpose of implementing cryptographic algorithms, the generic method is getting the relevant descriptive standard, grabbing your keyboard, and trying. Most standards include "test vectors", i.e. sample values which let you know whether your implementation returns the correct answers. At that point, things differ, depending on what kind of algorithm you are considering.

Symmetric cryptography:

Symmetric algorithms cover symmetric encryption, hash functions, and message authentication codes (MAC). You do not need to know much mathematics to handle these; most of it is about additions of 32-bit and 64-bit integers (that's modular arithmetic, with 232 or 264 as modulus) and bitwise operations (XOR, AND...).

Such code is usually done in C. Good performance is achieved by having some notions on how the C compiler will understand and translate the code into instructions for the CPU; knowledge of assembly is not strictly mandatory, but quite useful. An important parameter is cache memory: loop unrolling is usually a good tool, but if you overdo it, performance drops sharply.

I suggest beginning by implementing the classical hash functions (the SHA family, described in FIPS 180-3) and trying to make them fast. As a comparison point, get OpenSSL and use the command-line tool openssl speed to see what kind of performance can be obtained (this tool is already included in any decent Linux distribution, and it works on Windows and MacOS too). For instance, on my PC:

$ openssl speed sha256
Doing sha256 for 3s on 16 size blocks: 4842590 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 2820288 sha256's in 2.99s
Doing sha256 for 3s on 256 size blocks: 1262067 sha256's in 2.99s
Doing sha256 for 3s on 1024 size blocks: 395563 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 53564 sha256's in 3.00s
OpenSSL 0.9.8o 01 Jun 2010
built on: Wed Feb 23 00:47:27 UTC 2011
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           25827.15k    60367.37k   108056.57k   135018.84k   146265.43k

which means that OpenSSL includes a SHA-256 implementation hand-optimized in assembly, which achieves 146 MB/s when processing 8 kB messages. On the same machine, a pure C implementation ought to get to at least 130 MB/s.

For an example of how hash functions are implemented in C and Java, and how hashing speed can be measured in a meaningful way, see sphlib.

Afterwards, you can try symmetric encryption, in particular the AES (FIPS 197). It helps a bit to know what a finite field of characteristic 2 is, but the standard is clear enough to guide you through a perfunctory implementation. Then, try to optimize things. OpenSSL can serve as a comparison point, and get inspiration from the AES implementations of Brian Gladman. As for security, there has been some concern about what key-dependent information could be leaked through use of look-up tables in the implementation (try to search for "AES cache timing attack"); trying to reproduce that kind of attack is a very good exercise (mind you, it is not easy, but if you succeed in demonstrating it in lab conditions then you will have learned a good deal on how cryptographic implementations work).

Asymmetric cryptography:

Asymmetric cryptography is about the algorithms which involve more than one party. This includes asymmetric encryption (RSA, ElGamal), key exchange (Diffie-Hellman) and digital signatures (RSA again, DSA...). The maths contents are much bigger there, and optimization is a much broader subject than for symmetric cryptography, because there are several ways to implement each algorithm, instead of a single "obvious" implementation path.

A good reference is the Guide to Elliptic Curve Cryptography. Although it is mainly about elliptic curves, it includes a general treatment of the implementation of operations in finite fields, and it so happens that this is the sample chapter which can be downloaded for free at the URL linked to above. So get it and read it now. Another indispensable reference is the Handbook of Applied Cryptography, which can be freely downloaded; chapter 14, in particular, is about efficient implementation.

RSA is simple enough, and is adequately described in PKCS#1. There are possible timing attacks on RSA, which are countered by masking (yes, this is a paper "written by a researcher", but in the subject of cryptography, researchers are the people who understand what is going on). If you get the hang of modular arithmetic, you can try to implement DSA (FIPS 186-3). Diffie-Hellman is mathematically simple (it needs nothing more than is needed to implement DSA) but its describing standard (ANSI X9.42) is not downloadable for free.

Elliptic curves are a popular future replacement for modular arithmetic; EC variants of DSA and Diffie-Hellman are faster and believed more secure with shorter public keys. But that's more mathematics. There again, the Guide to Elliptic Curve Cryptography is the must-have reference.

There are other kinds of asymmetric cryptography algorithms, e.g. the McEliece cryptosystem (asymmetric encryption; there is a variant for signatures described by Niederreiter) and algorithms based on lattice reduction. But they do not (yet) benefit from published standards which take care of the implementation details, and there are not so many existing implementations to compare with. You'd better begin with RSA and DSA.

Cryptanalysis:

Cryptanalysis uses a much higher dose of mathematics than implementation.

For symmetric cryptography, the two main tools are differential and linear cryptanalysis; see this tutorial.

My own path to cryptography began by implementing DES, and then implementing Matsui's linear cryptanalysis on a reduced version of DES (8 rounds instead of 16). DES is described in FIPS 46-3, which is officially withdrawn, but still available. From DES can be defined Triple-DES (three DES instances, with three distinct keys, the middle one being use in "decryption" direction) and there are published test vectors for Triple-DES (also known as "TDES", "3DES", or sometimes "DES", which is arguably confusing).

For asymmetric algorithms, cryptanalysis mostly involves working on the mathematical structure of the keys, e.g. by trying to factor big non-prime integers in order to break RSA variants. Mathematics here range from the non-trivial to the totally unimaginable, so this might be too steep a learning curve to begin cryptography by trying to break RSA...


Can i increase my keys tested per second using a dictionary attack compared to bruteforce...?

Using a dictionary isn't going to increase your rate of attempted cracking, as the program still has to take the input, apply whatever hashing algorithm is required, and then compare with the password to be cracked.

The use of a dictionary is that if the password is the same as one in the dictionary (or similar if you're using mangling rules), you'll find it a lot faster.

Even large dictionaries are very small compared to attempting to guess every single possible password.


Safe Links is a feature that originated in Office 365 Exchange Online Advanced Threat Protection.  https://products.office.com/en-us/exchange/online-email-threat-protection

By wrapping the link, you give Microsoft a chance to check the URL before letting you through. So if it is say a link to download a virus or malware, it can show you a block page or warning page instead. The service also do some advanced stuff like visit the page on your behalf and scan for threats just in time, or show you the destination in a sandboxed page to prevent malware.

This is better than scanning the email at delivery time because some links may be to phishing sites or zero day malware that has not yet been discovered. But by the time you click the message in your inbox, it may have been caught (and thus will be blocked).

In a corporate environment, this is also helpful because it allows you to get metrics on who clicked on what. If an employee clicked through to a phishing site, you can look at the logs to determine who also clicked on that link as take action.


Performance will be many times slower than AES, any perceived security advantage will be minimal.

The additional key transfer and subkey generation for each block could create a timing attack vector, and you are now loading the primary key into memory for every block, vs AES alone which performs a single key expansion, then saves the subkeys in XMM registers (when using hardware acceleration), where it can then be secured from access by other processes.

The method you are describing turns a hash based stream cipher into a KDF to generate keys for each block. This might be acceptable if you are using CTR mode and are trying to prevent something that is nonce reuse resistant, and you then use the new key for each new message, rather than each block.

From a performance perspective, for each block you perform on average, 2 hash iterations, 1 key expansion, and 14 encryption rounds. SHA-256 takes something like 550 clock cycles (can anyone confirm?) per iteration, 14 rounds of AES with key addition takes something like 101 clock cycles, and the key expansion is up to 136 clock cycles. That gives you 1337 clocks vs 101, a 13.2 times performance disadvantage. Additionally because of the way the keys are generated, you can't really take advantage of multiple cores, another maybe 4X disadvantage, although you can use ECB mode since the key is different for each block.

In all, when compared to ECB and CTR mode on a quad core haswell CPU, you will be around 52 times slower, and 13 times slower than CBC.


Deciding CVSS v3.1 scope parameter for a XXE vulnerability

What does "Scope" mean?

The scope essentially asks whether the vulnerable component is also the affected component. Let's use a SQL injection as a simple example:

The vulnerable component is the web application. It just concatenates input into a pre-written SQL query and sends that to the database. The database is the component that is actually affected by the vulnerability. Afterall, it allows an attacker to arbitrarily read and possibly even modify data.

So to make it simple, it asks Who screwed up? and Who suffers the consequences?. If they are the same, the scope is unchanged. If they are different, the scope changes.

How does this apply to XXE?

As you said in your question, the vulnerability allows an attacker to perform a port-scan on your internal network. We can quickly see that the vulnerability lies within the web application, but the other hosts on the network are now affected as a result. This leads to the conclusion that the scope has changed.


How secure is Facebook Messenger when not using “Secret Conversations”?

Of course they can, they can access everything and anything that is uploaded, or used on their platform. Non end-to-end communication encrypts the data between you and Facebook, and the recipient and Facebook. So Facebook sees everything. The only exception is when using end-to-end communication, when data is encrypted between you and the recipient directly and Facebook may not be able to see the messages.

[Unless in a situation where the government gets a court order to disable the end-to-end communication feature so that messages are not encrypted when using end-to-end communications even though you think it is, but I am not a lawyer nor an expert on Facebook's terms and conditions]

For more information, read the terms and conditions, privacy policy and ad policy on the Facebook website: https://www.facebook.com/policies
Each website has their own conditions that you agreed to when you signed up or used their services.


Securing data on a mobile device (even from the user/owner)?

The important point is that you cannot hide secrets in software: if some software runs on the hardware owned by the attacker (here, the user and his smartphone), then the attacker can reverse-engineer the application code and extract the secret. If it was possible to protect software from that, then there would be no software or video piracy. Media industry would be very interested; they have looked high and low for a solution, and spent a lot of money on the subject, and did not find anything really robust.

So you need tamper-resistant hardware, i.e. hardware which will prevent reverse-engineering. In a smartphone, this indeed points at the SIM card: smart cards are, by design, tamper-resistant. In fact, the SIM card is the only tamper-resistant piece of hardware that can be found in a typical smartphone, so you have to use it. However, there will be additional challenges:

For proper protection, you must not use the SIM card only as storage; the point of tamper resistance is to never let the key exit the card. If the card just handed the key over to whoever asks for it, the attacker would have no trouble extracting it. So the complete computation must occur within the card. Depending on how programmable the card is, this may or may not be easy; in any case, the card vendor and the phone operator will have to be involved.
There is no clock in a smart card. If the algorithm depends on the current time, then that time must be obtained from the outside, and that "outside" is the phone, under full control of the attacker. The phone may lie. This would allow the attacker to generate the codes for, say, the complete next year. Depending on what you do with the codes, this may or may not be a problem for you; but you have to take that into account in your security model.

The clock issue might be avoided if you generate your codes not with a clock, but with a counter, like what is done with HOTP. A feature of RSA SecurID tokens is indeed that they include an internal battery powered clock that the user cannot tamper with; this is an expensive feature which explains both the size (substantially bigger than a smart card chip) and the price of these tokens.

Another way to avoid the clock issue is to use the network. The code in the smart card would generate a random challenge (say, 16 random bytes), send that to the phone; the phone would then talk to a Time Stamp Authority who would sign the challenge along with the current date and time, and send back the signature. The smart card would still have to verify that signature, and check that the response indeed contains the correct challenge value. This process ensures that the card obtains an untampered-with notion of the current time with decent accuracy. But the protocol has become quite complex, and involves network access (not necessarily easy, especially when the phone owner is in a foreign country) and a trusted server (which has to be maintained).


My ISP uses deep packet inspection; what can they observe?

Deep Packet Inspection, also known as complete packet inspection, simply means they are analyzing all of your traffic as opposed to just grabbing connection information such as what IP's you are connecting to, what port number, what protocol and possibly a few other details about the network connection.

This is normally discussed in contrast to the gathering of NetFlow information which mainly collects the information listed above.

Deep packet inspection gives your provider a lot of information about your connections and habits of Internet usage. In some cases, the full content of things like SMTP e-mails will be captured.

HTTPS does encrypt the connections but your browser has to make DNS requests which are sent primarily via UDP so that data will be collected as will any unencrypted links or unencrypted cookies sent incorrectly without https. These additional bits which will be collected may be very telling about what type of content you are looking at.

The larger concern for most people is about data aggregation, by collecting this information a data scientist could create a fingerprint for your Internet usage and later associate with past activities or activities from other locations (when you are at work or are on vacation). Likewise, your service provider may choose to sell this to any number of organizations (possibly including criminal organizations) where it could then be used against you in ways. In many countries, people have an expectation that their communications are considered to be private and collecting this data very much goes against that privacy expectation.

Another interesting aspect of this is in the cases like the US where this data may soon be sold it allows International communications sent to people, or servers, in the US be sold as well. Likewise, this could potentially allow every agency from local law-enforcement, military, tax authorities, immigration authorities, politicians, etc. a way to bypass long-standing laws which have prevented them from accessing this type of information, or important informational subsets within this data otherwise.

A slightly different concern when this data can be sold is competitive intelligence / corporate espionage. In the scenario where a company does a lot of research-intensive work at their headquarters located in some small geographical location (think of pharmaceuticals or a defense contractor) selling that data makes it possible for anyone to buy all of the traffic from the local ISP where most of those researchers live and analyze what they are looking for when at home, possibly even directly from the ISP hosting the traffic for their corporate headquarters. If other countries aren't selling similar data it gives foreign companies and companies wise enough to try and buy this data a huge technical advantage. Likewise, it would also allow foreign governments to buy ISP traffic which includes the data from US (or other government) Officials homes.

Imagine companies monitoring their employee's behavior at home or on their mobile devices.

This will likely have a chilling effect on activists and whistle-blowers as well.

Likewise, if credit cards or PII are sent in the clear to a poorly secured remote site your ISP's data set now has a potential PCI or PII regulatory issue on their hands. So this amplifies data-leakage problems of all types by making additional copies of the data leaked.

With the examples I've just mentioned above, and there are hundreds of others, it should be easy to see why this type of data collection has a different level of importance to it than just metadata or basic connection information. Even if your ISP never sells this data they are collecting quite an interesting dataset.

It's a security issue that definitely has a lot of potential long-term security implications.


I have not verified that, but the obvious way on windows would be to use CryptProtectData with CRYPTPROTECT_LOCAL_MACHINE.

At least that is the way passwords are stored in SQL Server Management Studio... reversable... ;-)


How can a company tell if my password is similar to the previous 5 passwords?

Could be done in a variety of ways:

Keep a list of the last five passwords used, hopefully encrypted.  Not the safest thing obviously, but certainly do-able.
Keep a list of hashes related to the last five passwords, e.g. full password, first X characters, last Y characters
Keep a list of characteristic patterns of the last five passwords, e.g. llllllllds.  l being letter, d being digit, s being a special character.  If the pattern is the same, but the hash different, then it's just too close.


What is Plundervolt?
Plundervolt is a vulnerability in Intel CPUs. These CPUs allow users to use privileged software interfaces to undervolt their CPU. Undervolting is the process of supplying the CPU with less power than specified, usually in order to conserve power. In this case, undervolting is used to induce faults into calculations.
By doing so, attackers can for example cause the SGX to write secret data to user memory.
Should the average home user worry about this? Is undervolting insecure?
No, for multiple reasons.
First of all, the flaw doesn't come from undervolting the CPU, but rather from the fact that Intel offers a software interface to undervolt. As a result, not undervolting doesn't stop an attacker from exploiting the vulnerability.
Secondly, the attacker requires administrative privileges on the machine. While this matters in the context of cloud computing applications, domestic users on their own machine usually don't need to worry - if an attacker has administrative privileges, they're f___ed either way.
Finally, Intel has released a security advisory and an accompanying microcode update to mitigate this issue.
Who should worry about this?
Anyone who relies on SGX to provide confidentiality and integrity, in scenarios in which potentially malicious actors have gained root privileges. In this case, it is possible that this attack has been used to extract secrets from SGX.


Unprotected connection to HTTPS web-page

Google Chrome displays a mixed content warning. Google has a good article outlining how to prevent this. Preventing Mixed Content. This is likely to protect against prior harm XSS has caused. Particularly when XSS is performed on a website without HTTP. Although, I cannot see how this would be a problem.

Mozilla Firefox displays the connection as secure without any security warnings.

Although, Opera seems to display the connection as "Unprotected connection" when the mixed content warning is given.
It can be seen that a secure HTTPS connection is established with a valid certificate and TLS 1.2, etc...

SSL Labs analysis shows yourdomain.com uses HSTS.

  Is it a problem with the website or with our machines?

As you can see from the results above, this is not an issue with the client-side, as Opera is designed to respond like this. Instead, it's an issue with the server-side, where the developer did not consider all browsers and how they would respond.


Sending secure information from app with ssl

Sending credit card info via e-mail is very bad and likely a violation of their merchant service agreement.  Credit card details must be protected in transit and e-mail leaves it flapping in the breeze.

The SSL connection to the server or not for transmitting form data is irrelevant unless the server is somehow encrypting the e-mail to protect it and even then it is really not a very good channel to use compared to storing the information protected in a database (still likely requires PCI-DSS compliance) or simply having it directly relay the user to the payment gateway itself to sidestep compliance issues entirely.


How to prevent cheating (extra votes) in online contests?

You're attempting to uniquely identify something through a system that was somewhat designed to not require a unique identity.  Short of tying and validating to a 3rd party (usually physical) identifier, this is impossible.  Instead, your best bet is to restrict voting altogether, in a manner that discourages automation and/or quick results.
If your system supports it, see about weighting the votes based on some criteria:

'Age' of the account (since signup).  Disallow votes for anything under some age (say, since the start of the contest).
Number of entries (in other contests).
Account activity (is the account visited/used regularily?) - comments in forums or on entries, etc.
Percentage of votes by user in contests since signup (may reveal 'targeted' behaviour).  Perhaps by number of different vote recipients?
Throttle votes accepted per-entry based on total votes per-contest.  Anything above a threshold gets flagged for review.

These all should be dooable from a database/reporting side, negating the need for any fancy javascript or other client-side code (which can be tricked).


What are the relation (difference and similarities) between Replay attack, reflection attack and relay attack?

These three have little in common. Only the replay attack can be really considered MITM, and even then, the MITM is only part of the attack. If anything, in theory reflection attack is a special case of relay attack, where you only use one device, though in practice they are very different.

Replay attack is partially MITM. Lets say you send an encrypted and signed command "OPEN_DOOR_1" to open a door on your smart home. Replay attack would be to capture the command and just send it again to open the door again, without knowing what the command is (encrypted) or knowing how to sign it (it is already signed).
Reflection attack is using the target to authenticate its own challenge. For example, you have two devices that authenticate each other and you use shared secret and HMAC to do the authentication. The target sends you a nonce that you are supposed to HMAC. You open a new connection with the target, request that it authenticates itself and send the nonce you received previously. You receive the HMACed response and send it back to the target pretending you HMACed it even though it was in fact the target.
Relay attack is usually used with smart-cards and tokens. You basically go to the terminal, with one device and to the smart-card with another. You just send the messages between to over distance. A nice example is in cars with wireless ignition, people were able to just use signal booster to boost the signal from the keys inside a house to the car outside, using the owners keys to unlock the car without ever entering the house or touching the keys and without breaking any encryption. Just making the car think the keys are closer then they really are.


What are the security differences between SMIME email and PGP email?

1: The advantage of S/MIME over PGP is that you sign/encrypt a complete mime entity, not a text. This makes it possible to sign/encrypt an entire message/rfc822. Yes, headers must be visible and changeable to the MTA, but that can be accomplished by taking the WHOLE mail, S/MIME sign or encrypt it, and then package the signed/encrypted S/MIME entity it in a new mail container. This accomplish can even be used to encrypt the subject, by having the inner (encrypted) subject be "Here is your credit report for your credit card number 1234-1234-1234-1234" and then the outer subject be "A encrypted mail from your bank!".

Most MUAs will react to a message/rfc822 container either by displaying a button, attached file, or Another UI element to open the "contained" message, or it will display the contained message inside the original message, like "iframes" work in browsers. Both of these allows you to validate all signed fields and all data, except for data that should be hidden according to the RFCs.
This makes it even possible to use even different from's for encrypted mail.

For example, the outer container has From: YourBank Info Department <info@yourbank.com> but the inner encrypted container has From: Name Namesson <name.namesson@yourbank.com>

However, there is one case, where its DANGEROUS to sign/encrypt/decrypt/verify a complete MIME container/entity instead of only plaintext. This is when someone signs/encrypt content that this someone hasn't created.

One example is a notary verifying that Im is a male, for example (I know it's a "stupid" example, but so you understand the dangers of signing MIME entities).

Let's say I ask the notary to sign the following:

Content-Type: multipart/alternative; boundary="1234";

--1234
Content-Type: text/plain

Im a male
--1234
Content-Type: text/html

Im a female
--1234--

If the signing is done with S/MIME, the notary will verify the content she/he see, lets say the notary's client is unable to view HTML mails and will then show the text/plain version. The notary signs is because the notary knows im a male.
I then forward the signed mail to a verifier, that has a HTML mail client, which will of course show "Im a female".

Another example is the following:

 Content-Type: text/html

 I authorize the transfer of $ 100 000 000 000

 from your account to my account 1234 1234 1234

You can propably understand what happens if you as a account manager signs this, and the target mail client, lets say the bank employee's mail client strips off HTML from the mail after having verified the signature.

In this case, PGP can have a great security advantage over S/MIME, because in PGP, you know exactly what you signing, encrypting, decrypting or verifying.

2: In PGP its easy as appending the unsigned data outside of the -----BEGIN PGP...----- and -----END PGP...----- . In S/MIME this is done outside of the S/MIME container. This can be done as in 1, repackaging the whole signed mail into a new message/rfc822 container, and then adding the disclaimer to the outer container.
But if you need to add a disclaimer to S/MIME mail, I would recommend using a gateway signing solution like Ciphermail, where the disclaimer can be added Before signing the mail.

3: The MTA can modify all outer headers in both PGP and S/MIME mail. MTA's shouldnt touch inner headers anyways (unless its signing, encrypting, decrypting or verifying mail). Some MTAs might recode content from 8bitmime to qp in case the receiving server does not annouce support for 8BITMIME, why its best to Always send signed mail as quoted-printable.

4: S/MIME do sign all headers that has a effect on interpretation of content, like Content-Type, by moving these headers inside the S/MIME container.
PGP should completely ignore the container and Always sign plaintext, however, MUA's might display the content inside a PGP armor with formatting, when it should not. In some cases, this can also affect the signature validation, eg if the mail client sends the visible content (eg with stripped HTML tags) to the PGP verifier, the content will come out as invalid.
The best way of this, is when PGP is used, Always use a external solution where the PGP mail is copyed and pasted. Or use a central solution that can recode PGP mail as text/plain to ensure these do not have any effect on the interpretation of content.

5: For both S/MIME and PGP, the signed data will be visible to the end user even if their clients do not support S/MIME or PGP. In S/MIME, signed mail will appear to have a attachment of smime.p7s for non-S/MIME-aware clients that can be safely ignored if you dont want to verify mail. For PGP, it will look like this:

-----BEGIN PGP SIGNED MESSAGE-----
bla bla bla

Best regards, Name Namesson
-----BEGIN PGP SIGNATURE-----
fkjhdklghdflhilgnegdngnlbvilgbdgeetbugbzjbeu
-----END PGP SIGNATURE-----

Thus the mail client user can see the content of the message, even if the client do not support signatures at all. If you want to add verifying instructions, you can easly add tihs INSIDE the signed mail (so it gets signed).

If you want to add such instructions outside of signed content, you can refer to Point 2 of my answer. For encrypted mail, in PGP its the same as for signed mail - eg add it outside the BEGIN/END header lines. For S/MIME, you have to repackage the mail, so the encrypted mail is put inside a message/rfc822 container, that is then added to a plaintext container, containing decryption instructions.

6: Yes you can hide To and CC in S/MIME by simply moving these inside the encrypted message/rfc822 container. However, its recommended to have a To, that is directed to the original recipient, to prevent the mail from getting discarded by spam filters, because spam filters might compare To: to the envelope recipient, and if it wont match, it sees it as spam.
However, CC can be safely hidden to only be visible to those having a key.

In PGP, its not possible, since PGP encrypts the plaintext. However, you can manually add a text like:
"I did send a copy of this mail to name2@somehost.com and name3@someotherhost.com" aswell in the beginning of the plaintext mail.

7: Yes. Intermediate MTA's can verify signatures inside mail. For S/MIME, this can happen completely transparent. In PGP, this can only happen if the key is uploaded to a key server that the intermediate MTA knows about and downloads keys from. Note that for MTA to MTA integrity, I would recommend using DKIM, STARTTLS and SPF instead. You can example configure your MTA to force STARTTLS to the mail servers you know support TLS.

8: No. Signed and encrypted message is Always a sligtly Little bit larger. This is something you need to account for if you signing or encrypting mails to hosts that empose size restrictions. In the same way, S/MIME and PGP will make the mails as small as possible, so encrypted mails do in fact "leak" roughtly which size the message is. However, its possible to hide the "true" size of a enrcrypted message, by padding it with useless data. You could even add a notice like "This is a padding to ensure encrypted data Always has the same size." and then add large blocks of lorem ipsum text. Note that the size of lorem ipsum block must not be smaller than the largest mail, else people can see in the encrypted content which mails that are larger than a certain size.

Note that S/MIME signs or encrypt all text as once, in a large block, and then adds the smime.p7s attachment. A encrypted S/MIME mail will ONLY have the attachment smime.p7m , PGP does encrypt attachments separately, why the size leaks for those. PGP attachments are encrypted in whole. PGP attachments are signed by appending a new attachment to the mail that contains the signature . For example, Powerpoint.ppt is signed by appending the attachment Powerpoint.ppt.asc to the mail, so the mail contains both the Powerpoint.ppt and the Powerpoint.ppt.asc file.
However, if you want to hide size of attachments when encrypting, you can Always put the attachments in a .zip file, and then inside this zip, you put a useless file such as large that makes all your zip's a fixed size. Note that you then need to calculate the size of the useless file based on compression (or turn off compression), and the useless file needs to be random data. When you encrypt this zip containing your attachments and the useless file, it will be transformed in one single binary blob, where those that does not have the key, cannot see anything about the size, name or number of attachments you have sent.

9: Yes, provided that the gateway knows the private key of the receiver. This is valid for both PGP and S/MIME. If you want to gateway audit mails to recipient who you dont know the private key to, you can Always encrypt the mails from the gateway, and send the mails "unencrypted" to the gateway, but encrypted by some other means like STARTTLS, and/or PGP/SMIME encrypted with a key that the gateway knows the private key of. If the third-party is located off-site, you can Always add the 3rd party's key as recipient in both S/MIME and PGP, allowing the auditor to decrypt in addition to the real recipient.


Could somebody explain how the ASDA site is vulnerable?

The blog post from Paul Moore holds back quite a lot of information, probably on purpose, seeing that asda hadn't fixed the issue when he published the post.

Here is an article that is a bit more explicit about the vulnerabilities of Asda.

CSRF Vulnerability

First of, they did not seem to have any CSRF protection:

  There is no XSRF protection throughout the site. It's possible to remotely hijack any active account without knowing the username/password

The impact of this depends on what a user can actually do on the website (because that is what an attacker can also do with CSRF, except if a user has to enter a password for the action). From the description, it doesn't sound like it's too much though:

  It's also possible to add/remove items to the basket from a remote site and ship to an alternative address, increasing the risk of fraud/identity theft.

This is obviously still bad though.

CSRF to XSS

  In the exploit he goes to another site with the malicious payload in another tab, and upon switching back to the ASDA page a form appears asking for credit card info which his server sees when submitted.

I couldn't find any information on this, but a save bet is that this is an issue of persistent XSS via CSRF (or maybe reflected POST XSS via CSRF).

What is probably happening: Some form field on the website is vulnerable to XSS via POST, either reflected or persistent, and this can be exploited because there is no CSRF protection.

Normally, POST XSS issues in a user area wouldn't be that big of an issue (although you still shouldn't have them), as CSRF (and possibly ClickJacking) protection prevents people from exploiting it (if the login is also CSRF protected).

But as there is no CSRF protection, the XSS vulnerability in the user area is now exploitable. As XSS is quite a bit more powerful than CSRF, this is a problem.

The attack code might look something like this (it's made up to illustrate the point):

<form action="https://example.com/profile.php" method="POST" id="myform">
  <input type="hidden" name="name" value="<script>alert(1)</script>" />
  <input type="submit" value="Submit request" />
</form>
<script>document.myform.submit();</script>

If a user visits a website containing this code while logged into asda, their profile would be updated, and the injected code would be executed in the context of the asda site.

As you can see, the XSS payload in the example is submitted by the victim, meaning that browser filtering will likely protect some users. However, it is likely that  an attacker could create a new account, inject the payload in that account themselves, and then force-login a victim via CSRF, bypassing browser filtering. If a victim does not notice that they are logged into a different account, they may still provide sensitive information.


Does PayPal support a backup code for two-factor auth?

Yes & No. It's not a simple backup code, it's a series of questions to confirm your identity.

https://www.paypal.com/us/cgi-bin/webscr?cmd=_security-key-faq#breakmyToken

**Can I still log in to my PayPal account if I lose or break my key, or if I don’t have my mobile phone with me?**
Yes. During login, we’ll ask you questions to help confirm your identity. When you answer them correctly, you’ll be able to log in.


How do I correctly select and use a modern symmetric block cipher?

This should probably be on the crypto Stack Exchange instead of here.

Regardless, the best course of action is to not touch the symmetric block cipher yourself. There are mature, cryptographer-audited security libraries like NaCl and KeyCzar that will make the correct decisions for you.

That said, if you do choose to go it your own, a generally safe choice is AES-128 in either EAX mode or GCM mode. Both of these modes provide authentication of your ciphertext in addition to cryptographic security, which is crucial for avoiding things like padding oracle attacks. In order to use either of these modes, you need a cryptographic key, an initialization vector, a plaintext, and, optionally, additional authentication data.

The key must be 128 bits long and generated with a cryptographically secure random number generator. If you want a password-protected key, take the randomly-generated key and pass it through PBKDF2-HMAC-SHA-256 with the password, the key in place of the salt, a number of rounds calibrated to take as long as you're comfortable with (10_000 rounds on my laptop requires 0.5s, which is a reasonable amount of time), and a 128-bit output size. The output will be the "real" key to use, and you can re-run this with the original key and password any time you need to access the real key.

The initialization vector for EAX and GCM modes (note: this may not be the case for other modes, like CBC, which has even stricter IV requirements) must be unique across all encryptions with a given key. A simple counter is considered to be sufficient. However, you need to make sure this counter guarantees uniqueness even when run across multiple invocations of the process, multiple simultaneous processes, and multiple machines. A properly-implemented version 1 UUID should suffice for these purposes. This isn't in the format encouraged by RFC 5116, section 3.2, however, and someone more knowledgeable than me will have to clarify whether or not that format is important to abide by. Alternatively, a securely-generated random number of appropriate size should be sufficient, but I haven't seen people do this in practice with CTR-derived modes (which GCM and EAX are based off of). Again, someone more knowledgable will have to comment on whether or not this is a good idea.

The plaintext can be anything you please, but do not fall into the trap of thinking the input of AES is "characters", "ASCII", "Unicode", or any such nonsense. The appropriate input is an array of bytes.

The optional associated authentication data may also be anything you like. This is data that is incorporated into the ciphertext in order to verify authenticity when a decryption is performed. But it is not part of the plaintext protected inside of the ciphertext. For example, if you're encrypting data on behalf of users stored in a database, you could use the user's user_id in the database. In the event that one user found a way to copy another user's encrypted data into his account, he wouldn't be able to get your application to decrypt it, since his user_id wouldn't match the one used to encrypt the data. I may have explained this poorly, so please let me know if it was confusing or unclear.

For storage, the key must be kept secret. Key management and lifetime is beyond the scope of my answer, but it is a crucially important part of ensuring the security of your protected data. The initialization vector, ciphertext, and authentication data have no requirement on their secrecy, but the authentication data should ideally be something provided to the cryptography layer from an external source (e.g., the user_id mentioned earlier). When used, it should not be something a potential attacker can supply to you or otherwise exercise control over. Storing, transmitting, and copying the authentication data along with the other values defeats the purpose. One way of considering the authentication data is that it should provide "context" for the protected data.

That should do it. Keep in mind that this is complicated, and excruciatingly difficult to do correctly without leaking protected information. I don't recommend you go it on your own, but if you do, the above should be a relatively safe point to start from. At the very least, you should be better off than 95% of the websites out there that try to implement cryptography themselves. Assuming, of course, that I haven't completely failed at describing a secure implementation approach.


How to securely derive a second password specific to an user

I want the wallet's passphrase to be unavailable to anyone but the logged-in user (session persistent), so that nobody, even server administrators, can look at the wallet's password and make transactions from the wallet.

That nobody is able to know what the passphrase is for any specific user, not server admins looking at databases/server sessions, not hackers breaking into the server and writing scripts that leak the passphrase, not myself.

While you can protect this against storage, an Administrator can put in some extra logging to capture this information. There's nothing you can do about that, except store the secret on the Client as @Ethan suggested. (which could be better or worse for security depending on who your clients are)
I'm going to answer with the assumption that you decided that the server needs access to the secret directly. (in which case also storing on the client would be pointless)
You can prevent plain storage server-side, assuming no malicious logging has been installed.

I'm already encrypting user account passwords with bcrypt.

Encryption is reversible with the key. Hashes are one-way. BCrypt is a hash, not encryption. (and that's a good thing)
Make sure you have a strong work factor. It should take at least 100ms (with appropriate DoS protection) to calculate the BCrypt hash. Note that attacker's hardware (should the hash be stolen) will probably calculate these hashes much more quickly when they try to brute-force.

A passphrase that only a logged in user "has access" to. (Not directly, but through their session).

When the user logs in, the server will have the information needed to decrypt the secret.

isn't required to type in a second password or type in their account's password every time.

There is going to be some password that decrypts the secret initially. This can either be the first password they use to log in, or a 'special' password if you prefer. After that, the secret will be continuously available as a part of the login session.

Is this possible at all?

Good question. The answer is Yes, I've outlined how this can be done in the below question. Basically you just need to derive encryption keys from the user's password, and then from the session token. Both of these should be hashed (not just the password) so that the attacker cannot access the original text from which the encryption key was derived. The Session Token should have enough entropy so that you can use a Fast Hash.
Once you have the encryption key management worked out, you can just store the encrypted secret on the server.
How can we serve sensitive encrypted data without storing the key? Should I use user-defined passwords for keys?
Except, in your case, instead of serving the encrypted data, you'll just be using it internally on the server.
Please read this over, and post a new question or comment if you don't understand how it can apply to your situation.
And of course, make sure your application is secure from attackers (non-admins) to begin with. That is the most important thing.


resolv.conf: my router acts as a nameserver - a vulnerability? How to change it?

This is not inherently a security problem and rather useful. Some routers do use the information they have at hand to generate domains for your local devices such as tv.lan, router.lan and pc.lan, thus simplifying inter-lan-connections and making them independent from ips (usually assigned via dhcp by the router also).

If an attacker gained access to your router, changing the answers of your routers dns-cache would be possible - but then again, rerouting whatever traffic comes for whatever IP would be, too.

So there is no significant gain in security from disabling your routers DNS (or not using it). It would just make your browsing experience a tiny bit slower.


Can we use same Active directory / Proxy servers for PCI and Non PCI Segment users?

It all depends on how it's implemented but yes, it is certainly feasible. Let's say you have network segment A containing systems which handle cardholder data, network segment B with AD servers and network segment C with systems which do not handle cardholder data in any capacity, do not have access to segment A and management of systems within A and B is performed using a bastion host or jump server within segment B. In this scenario, there could be effective segmentation and, depending on security controls implemented, you should be looking good for using the same AD throughout. Throw in proper Role Based Access Control, monitoring and logging, risk assessment etc and you're getting closer to compliance.

As for the proxy, is the proxy transmitting cardholder data and what security posture/risk has it? The likelihood is that the proxy server will be considered to be in-scope though it could be used by both in-scope and not-in-scope systems.


Install the "NoScript" plugin for Chrome which could add an extra layer of security by preventing drive-by attacks.
And the question whether your device is compromised would be hard to tell, keep an eye on unsual behaviour within your browser, keep your a/v up to date and if you have the ability to sniff your network traffic, you could examine whether there is C2 traffic.


Mail server security: Mails to internal receivers with faked sender address

The problem that you are describing is known as spoofing, where you are able to send a message from personA@company.com, even though you are not personA@company.com.

Because the SMTP protocol dates back to the early 1980's, when the internet was in its early stages and used only by a relatively small number of users, the engineers of the SMTP protocol did not foresee the problem of spoofing. Because of this, users can easily send messages appearing to have been sent from any sender that they choose.

To counter the problem of spoofing, message authentication methods have emerged. These methods are used to determine whether the sender's address appearing on a message is likely to be legitimate, or whether it is likely to have been spoofed. By authenticating whether or not a message was likely to have been sent from the sender that it purports to have been sent from, spam filters can more accurately determine whether or not a message is likely to be spam. Two standards that have become widely used for message authentication are Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).

SPF is a way of publishing the IP addresses of mail servers that outbound mail for a domain is authorized to be sent from. This enables spam filters to determine if a message was likely spoofed. If the message was sent from a mail server whose IP address is not listed in the SPF record for the domain of the purported sender, then the message is likely to have been spoofed. SPF records are published as TXT records in the DNS for a domain.

DKIM is another method for authenticating messages. It's an outgrowth of an earlier standard, known as DomainKeys, and is based on public key cryptography and digital signatures. Using DKIM, the message is digitally signed by an entity - which can be either the sender themselves, or a third party. The signer's public key, which is used for verifying the signature, is published in the DNS for their domain. When a message is signed, the DKIM signature is placed in the header of the message. Upon receipt of the message, the signature is verified using the signer's public key. If the signature is valid, then this indicates that the signer has vouched for the authenticity of the message. UltraSMTP can DKIM-sign your messages on your behalf using our keys, or messages can be signed by UltraSMTP using your keys.

Your company's domain should have SPF or DKIM information published in its DNS.  If you configure your incoming MX to check that incoming messages appearing to have been sent from users in your company's domain have been sent from an SMTP server included in your company's SPF record, or contain a valid DKIM signature, then it can use this to flag these spoofed messages.


Here is my question: Could I run a simple server (like described
  above, access to file system/registry, network access) as NETWORK
  SERVICE? Are these 2 users provided by MS for such a situation?

Yes you can and you should. The network service account is (as I remember it) the least privileged machine account with limited permissions.You actually will get an Insufficient  Exception, if it turns out, your application requests resources for which the Network Service account does not have the rights to. You would then simply grant rights to what ever resource you're trying to access and then build on that, but for your high level requirements you describe here, access to file/registry and network it should be sufficient.

True, if your application creates a new eventlog source or registry key, you would need to explicit grant the rights to the network service account, should be no big deal for you/devops.

You could also consider using a domain account, say if you want to isolate your application/service from how shall I say it: an over time fragmented permissions changes to the general Network service account.

I would suggest you read up on those accounts in general:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686005(v=vs.85).aspx

  If you succeed to inject code into a php application running on apache
  as www-data you still need a tedious privilege escalation to fully
  compromise the machine

regardless of priv. esc. of (www) is tedious or less tedious (personally I think it's pure fun), if you're at that point where you found a bug in your service that can be priv. escalated, it usually boils down to poor patch management on your box and not so much your service at that stage.


How can NSA implants and backdoors be detected?

You are unlikely to detect a backdoor even by disassembly. These things are baked in to chipsets that maybe the BIOS doesn't even touch.

Perhaps, if you install a mirror port on your line then monitor to see if there is encrypted UDP traffic being transmitted to somewhere. UDP doesn't need a reply from the far endpoint. It doesn't even need to be sent to a real IP address - the authorities will intercept it in transit. Lack of a real IP target means its 'deniable' and untraceable back to who is the actual receiver, or if it is a real IP, it could be a false diversion.

I imagine if you work in the North Korean embassy even this is not sufficient.

If the authorities go looking for needles in all the haystacks they will find lots of sharp pointy things that aren't needles. The false positives will be your problem not theirs.


Is OSX or Mac hardware used in the InfoSec world? What resources are available?

The penetration testers over at Pauldotcom are perhaps the most famous security practitioners that openly talk about using Macs for their penetration test. From my personal experience, I've seen a number of digital forensic security practitioners who prefer using Macs.

As far as running your penetration tests, its likely easier to run your penetration test from a VM running a Linux distribution such as Backtrack 5 and utilizing Metasploit/Penetration tool inside the distribution. Whether you do this from a Mac/PC or Linux platform should make no difference inside the VM.

Here are some additional links that I found that may contain useful information on using Macs for Penetration Test:

https://web.archive.org/web/20130306081803/http://www.techrepublic.com/downloads/investigate-mac-os-x-as-a-platform-for-penetration-testing/293669

http://www.pen-tests.com/penetration-testing-linux-vs-windows.html

Goodluck!


Is a modal payment over HTTPS secure if the main page is only HTTP?

There is no "modal window" there is content which might be intended to contain an iframe pointing to a secure URL, but since it is invoked from insecure javascript and html it is vulnerable to modification. And as an iframe the user does not get to see all the meta data displayed in the browser chrome when you navigate to a secure URL.

Not only is this insecure it is visibly insecure.


Stop User Enumeration requests on AJAX endpoints

The cause of your problem:
Your system has a major design flaw where it's giving away information that it shouldn't offer openly. You've created a leak and someone is using it against you.
Now you could go great lengths to get get rid of the hacker, but in the end you're simply fighting windmills trying to block someone who's using a botnet. And even if you actually succeeded in the end - which is extremely unlikely in the first place - all you're doing is treating the symptom instead of the actual problem.
How to solve this:
Legitimate users know whether they're signed up already or need an account first. So fix your login form, nuke that endpoint and you're good.


How to safely handle non public data in memory

For your first question:

If Alice's machine is compromised, her private data is compromised too. There's no way to protect this "non public data" from someone who has access to the machine generating it. Of course I am assuming low level access here (administrator or VM-host), if the machine is shared but has proper user level security, then it may be okay.

For the second question:

Handling private data on cloud providers is indeed a bad idea. There is absolutely no way to keep anything private from the host machine while operating inside a VM.

When I see people trying to run privacy services in the cloud, it always makes me cringe.


Simulation of cloud based digital signature with Hardware Security Module (HSM)

Your question seems peculiarly obscure to me, so I'll write here some explanation about the meaning of the terms you employ, under the hope that it will reduce confusion and lead to either an answer or at least a clearer question.

PKCS#11 is an Application Programming Interface: it is a set of functions, that applications use, and that are provided by a given device or system. From the point of view of an application, a "PKCS#11 driver" is a DLL that the application can load, and that DLL offers some functions for creating and using cryptographic keys. The application does not know how the keys are created and managed and used, and that is the whole point of using a standardized API. A physical device for managing keys (says, a HSM) will come along with a DLL provided by the HSM vendor, the DLL implementing the PKCS#11 interface. That way, any application that knows how to load a PKCS#11 DLL and call functions in it will be "instantly" compatible with all HSM that provide such a DLL.

There is no need for the key management system to be "physical". The application calls the DLL, and the DLL does what it wishes; it may use files and simple software to perform the cryptographic operations; it may call upon some remote server to do the job; or anything else. The application, by definition, does not know and cannot know what the DLL does.

Presumably, if you want to simulate things, then you could imagine using a PKCS#11 DLL that does things in pure software, so that you may develop and test your application before actually buying a HSM. That's the theory; it does not work well in practice because PKCS#11 is a huge API, and while PKCS#11 specifies functions and arguments, it does not pin down all possible behaviours, so implementing PKCS#11 is only one step towards interoperability. Speaking of which, not all HSM are equivalent to each other, so making tests with one HSM does not mean that your application will run with all HSM on the market.

To make things simple, if you need to simulate a HSM from vendor XXX, then the best, most faithful simulation is probably the simulator provided by XXX itself, because that's the point of such a simulator. Mind that "best" does not automatically mean "good".

CryptoAPI is a Microsoft-only API that is somewhat analogous to PKCS#11. Applications call CryptoAPI's functions to perform various operations related to cryptography (including signing documents or validating X.509 certificates). Some of these operations are about key creation, management and usage; CryptoAPI delegates these to what Microsoft calls Cryptographic Service Providers. The CSP really are DLL that CryptoAPI loads; the CSP implements some standardized functions and handle access to the system (physical or software device) that does the job. A CSP is similar in concept to a PKCS#11 DLL; the difference is mostly that CSP exist only in Windows, while PKCS#11 also works on other operating systems.

So applications on Windows have the choice between using CryptoAPI or PKCS#11. The Firefox Web browser, for instance, uses PKCS#11 exclusively, when it needs to talk to cryptographic hardware devices (especially smart cards); for the same purposes, Internet Explorer will rely on CryptoAPI.

Some HSM vendors (e.g. Thales) provide both a PKCS#11 DLL and a CSP for CryptoAPI with their HSM.

"Cloud-based" and HSM are a weird combination. When you do things "in the Cloud", you send your data to be stored and processed somewhere remote, so that the whole thing may be virtualized and moved around without changing anything on your side. You normally want to use HSM precisely so that such things do not happen.

Possibly, you might want to mean that you will have a "shared HSM": the HSM will be located in a network-reachable location, and various client systems will delegate cryptographic operations to this HSM through an HSM-specific protocol (presumably a protocol with enough cryptography to make that secure). Still with Thales HSM, they have a product called "nShield Connect" that does exactly that.

Calling this HSM-sharing "cloud-based" is a rather confusing statement, though.


No SSL, no security. Things in the real world are rarely simple, but here it is the case. This is easily seen as follows: whatever you do in Javascript, will be done in Javascript sent by the server. Any attacker who is in position to look at the data can also modify it at will (e.g. the easiest way to spy on WiFi is to run your own fake access point, and then you naturally get to modify all data as it comes and goes); thus, such an attacker can simply remove or alter whatever Javascript-based solution you may come up with, and deactivate it. Or just add a hook to also send the password in the clear as an extra parameter.

Now, even if you could get "safe Javascript" on the client browser, then you would run into all the problems that Javascript crypto entails, and that are detailed in the article you link to. But this is only a secondary consideration, compared with the fundamental flaw explained above: with no SSL, you cannot ensure that what runs on the client browser is your code.

Trying to handle password securely on a non-SSL Web site is akin to trying to perform brain surgery safely with only a tea spoon and a rusty crowbar. Just don't do it. If there is sensitive data that flows to the Web site (e.g. names and addresses), then you MUST apply reasonable protection mechanisms. If the data is not sensitive, then why would you need passwords ?


Isolate two hard drives with two operating systems

There are devices with a physical switch between two HDDs.
There is no way to virtually isolate the drives. If you used encryption on both drives, it would make it very hard to access data on the second drive from your sandbox, but it would still be very easy to delete it.
So the best way would be to use a physical switch between your two drives.


Does storing Base64 encoding of scrypt password hash make it more vulnerable?

If you're storing only the hash itself as base64, this shouldn't materially alter the one-way nature of the hash or its protection of the original plaintext.

As long as no other pre-hashing plaintext data or related metadata is included (that would in any way hint at potential plaintext), then a leak of base64-encoded hashes wouldn't be any easier to attack than a leak of the original hashes.

An attacker would simply analyze the data, discover that it consists of base64 strings, convert them back to their original hashes form, and then carry out the attack. This won't slow most attackers down, but it also won't make things any easier for them.


How can a computer found on traceroute show all ports closed?

Regarding the Nmap results, I have three remarks:

you only scanned 1000 from 65000ish available ports (130000ish when you add together TCP and UDP)
you might not be allowed to access any ports on that router. So called ACLs, access control lists, control which source might have access to a port or not wether it is open or closed.
there might very well be no ports open. Routers are IP (layer 3) devices, often embedded and built solely for routing purposes. Ports on the other hand are on TCP and UDP, which are layer 4.

As to your follow up question of „I can trace route it, there must be a port“:

What trace routing is is sending a packet to the final destination host over and over again, starting with a TTL (time to live) of 1 and increasing that TTL.

The specifications of IP say a router should inform the sender if instead of routing the packet further it was dropped due to a TTL of 0. (routers are to decrease the TTL on every hop by the number of seconds it took them to process, at least 1.) This is done in the form of an ICMP packet sent from the router to your machine and catches and correlated with the packet it sent out.

Hence, for you to be able to trace route the router, you do not need an open port. As it does send ICMP messages, it should however respond to an ICMP echo request and nmap is telling you that correctly (with “1 host up”).


What are the possible ways to exploit a login page?

Some thoughts:

View the source code for information that may allow you to breach the login page. Developer comments, variables used for authentication
View the page to see if its using a known framework with security issues. Find the version number and look up related CVEs
Proxy the request across and view the content. Tamper with information being passed across to see if it allows access
View the content of cookies if there are any to see if that data allows access (seriously I've come across access=true in the past)
Try going around the login page if you can guess some urls, they may have poor access controls on the page you are trying to get to
View the site itself for information. Use something like dirbuster to see if there are any directories open to you that relate to the login page. Maybe a user list of plain text password file
See what the login page is being hosted on. Maybe there is an exploit on the host platform you can use to gain access or get around the page
Use a list of user / passwords from previous breaches to try brute force access


Which private-key encryption should I use for server to server communication?

Writing your own encryption is never a good idea. Even trained cryptographers (I mean people who have studied the subject for years, have a big shining diploma [a PhD] to say it, and, more importantly, have done and published actual research) do not think about using an algorithm or protocol that they have designed before having submitted it for inspection by their peers for several years.

On the more anecdotal:

"Checksum" is a large term; cryptographers prefer Message Authentication Code, which is much more precise.
"Long and multiple rotating keys": this sounds like a Dan Brown novel, and, security-wise, that's not a good thing.
Do not use /dev/random, use /dev/urandom.
"How much data it takes before the key runs out and is going to be re-used": this sentence makes sense only if you consider the kind of encryption systems that were used during World War I, that is, before the invention of the computer.

I do not know of any kind way of stating this: you feel confident, but you really should not.

Use TLS (the new, standard name for SSL).


What does "fd" stand for in the context of public key infrastructure?

As @CodesInChaos stated;

If you read the complete chapter, you see that the author is setting up a cert for Feisty Duck Ltd, CN=www.feistyduck.com, it's just the name for that.

As you said also, I understand that the key could be named anything; so the "fd" stands for nothing here, in terms of context in PKI.


Is this JSON encoding vulnerable to CDATA injection?

The //<![CDATA[ hack is used in XHTML pages that have to parse as both HTML and XML.

In the HTML parsing rules, <script> and <style> are special “CDATA elements”, whose contents up to the next </ sequence (HTML4) or </script sequence (HTML5) are raw data, so if (x<y) can be written without any encoding; this would foul up XML parsers.

In the XML parsing rules there are no special elements and so the same statement would have to be written as if (x&lt;y); this would foul up HTML parsers.

In order to allow < to be written unescaped and mean the same thing to both XML and HTML parsers, you can wrap the script in an XML CDATA Section, then protect HTML parsers from that odd construct by hiding it in a JavaScript comment.

If you are using this construct to allow you to include these characters in a string literal without escaping, it's not enough, because you still have to escape away both the sequence </ (for HTML) and ]]> (for XML). One way of escaping those sequences in a JS string literal is to always encode <>& characters to \x3C, \x3E and \x26 respectively... in which case you would no longer need the CDATA Section.

  I run the objects through a standard JSON stringifier which follows all the rules, then I replace </script with <\/script, not case sensitive. Is this sufficient?

Not necessarily.

HTML syntax. <\/script is fine for HTML but not XHTML, as above.
JavaScript syntax. There are—due to an unfortunate oversight in the design of JSON—some Unicode control characters that are valid in JSON but not valid in JavaScript.

Most notably the characters U+2028 and U+2029, Line and Paragraph Separator, which act as newlines. Injecting a newline into the middle of a string literal will most likely cause a syntax error (unterminated string literal).

There are more control characters that are supposed to be invalid in JS string literals, but which don't actually break browsers in practice.

If your JSON encoder habitually encodes all non-ASCII characters this won't be a problem.

Alternative to getting embedded JS-encoding right: avoid inline scripts completely, put your data in the HTML page (where normal HTML-escaping rules apply) and retrieve it from linked scripts using DOM methods.


Boot or reboot to clean state on Windows each time?

You can take a snapshot of a freshly installed Windows VM and revert to that snapshot each time you want a new OS.
You can automate restoring by using the VBoxManage tool:
VBoxManage snapshot restore <uuid>|<name>

The VBoxManage snapshot command is used to control snapshots from the command line. A
snapshot consists of a complete copy of the virtual machine settings, copied at the time when the snapshot was taken, and optionally a virtual machine saved state file if the snapshot was taken while the machine was running. After a snapshot has been taken, VirtualBox creates differencing hard disk for each normal hard disk associated with the machine so that when a snapshot is restored, the contents of the virtual machine's virtual hard disks can be quickly reset by simply dropping the pre-existing differencing files.
The restore operation will restore the given snapshot (specified by name or by UUID) by resetting the virtual machine's settings and current state to that of the snapshot. The previous current state of the machine will be lost. After this, the given snapshot becomes the new "current" snapshot so that subsequent snapshots are inserted under the snapshot from which was restored.
The restorecurrent operation is a shortcut to restore the current snapshot (i.e. the snapshot from which the current state is derived). This subcommand is equivalent to using the "restore" subcommand with the name or UUID of the current snapshot, except that it avoids the extra step of determining that name or UUID.


What's the next step if an organization doesn't respond to warnings of a potential data breach?

The next steps would depend on the type of organization they are. I will only list examples in my answer as a complete answer is impractical.

Health Care Organization

If this organization works with patient health information (PHI) then you can file a complaint with Department of Health and Human Services as described on their website.

Retail Merchant Accepting Credit Cards

If this merchant accepts any credit cards, they are subject to PCI requirements. Violations of PCI standards can be reported to the payment cards brands, per PCI council guidance.


Conflict between cipher-suite and certificate

its the session to google server called ssl.gstatic.com

In short: the ECDSA in the cipher suite refers to the key of the sites certificate. The RSA in the signature refers to the key of the certificates issuer. In detail:

To check what kind of certificate you get with this cipher:

openssl s_client -connect ssl.gstatic.com:443 \
   -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256' -tls1_2 -servername ssl.gstatic.com \
  | openssl x509 -text

This gives a certificate with an EC key, as expected:

Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
...
Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.google.com
Subject Public Key Info:
   Public Key Algorithm: id-ecPublicKey
      Public-Key: (256 bit)

But even if the certificate itself uses an EC key it is signed with an RSA key:

Signature Algorithm: sha256WithRSAEncryption

This is because the signature is created by the issuer and is thus using the key of the issuers certificate. And the issuer is using an RSA key:

Subject: C=US, O=Google Inc, CN=Google Internet Authority G2
Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)


Should I install an SSL certificate for a website that uses a third party payment gateway?

I'm going to interpret this questions as "should SSL be enabled on this client's web server or not?" Regardless of credit card information it is still going to be collecting personal data on the client's customers, and therefore SSL should be enabled. Besides protecting the brand and providing a safe site to shop:

It will help protect the client from liability
It may be required by laws or regulations depending on where the site is hosted, or the clients it serves
It's easier and cheaper to prevent data breaches than clean them up later


How can someone know technically if antivirus provider tracks him?

You can check 'event logs' of your system to detect the activity of your antivirus program.


Can .htaccess and .htpasswd really protect me?

I can store various sensitive information. However... I want to put it on the Internet

Yikes, as they say...

In this specific scenario, there are three issues:

The security of your authentication mechanism. You probably need to use TLS to protect this resource, since http basic auth really is basic - plain text, over the internet. Likewise, digest auth sends digests over the internet. Not much better. There's also the threat of interception unless you use TLS, so basically, TLS (https) is pretty much mandatory. The next step here is whether or not infinite re-tries are a possibility - in other words, can you prevent a dictionary attack? SSL is all very well, but unless you use client side certificates anyone can connect and repeatedly try passwords, so you need to ensure whatever web server you're using is configured to deny requests after X attempts. What you have available and can enforce should inform your decision to go ahead with this.
The security of the storage mechanism. If you're using a VPS, your hosting provider can almost definitely log in and definitely have disk access to your VM. If you have a dedicated server, that's a different issue. If you're planning on a shared host, be aware a compromise in one of the other 1000 or so websites running from that box could potentially expose your information. Encrypting that content will require you to have available a key to decrypt it, either on the server (this issue applies) or on the client (the issue below applies). Again, what setup you have available should inform your decision.
The security of the system on which you access that information. A similar question cropped up a while ago for a different purpose, but basically there is no way to force the client system to securely forget the information unless you have full control over it. As an end user and using TLS, you have a greater idea of what is going on, but even so, should you choose to access that information at a cyber-cafe, there are scenarios in which that data can be recovered. Any read is likely to store that information locally for processing and must decrypt it locally, even if it isn't cached, so there is a threat of interception. How much of a threat you think this is again should be something you take into consideration.

How much of an issue these factors are depends on how valuable the information you're storing is to you and to what extent you think you're at risk. For example, my main online bank and online store accounts all point at one email. I wouldn't be comfortable accessing any of those, or their login details, on a cyber cafe computer. However, I have a day to day email for mailing lists and other such info that is far less critical if compromised. So I would have fewer issues using that. If the risk is acceptable to you in storing this information on a wiki, then do it.


is it possible for a user to get the firebase auth token from a released app?

If at any point you send data to a device the user physically possesses, they can extract it. (This is why DRM doesn't work.) If you want to start asking questions about "how hard" this is, the answer is that it should be super easy, and the degree to which it is not is the degree to which the device fails to meet the definition of a general-purpose computer. If you wouldn't do what you're doing in your app as part of an ordinary program intended to run on an ordinary computer, don't do it just because it's on a phone.

If you'd like a more detailed assessment of "how hard" extraction of this specific auth token from your app is, let's run an experiment: send me the APK, and if I can find out the token you pay me $100. If that sounds like a bad idea, ask yourself how you intend to make sure that no one with threatening levels of skill and curiosity ever gets ahold of your app.


What are the differences between the RSA, DSA, and ECDSA keys that ssh uses?

What are these files for?
These are your host keys uniquely identifying your host. When OpenSSH is started for the first time, it will generate these keypairs. When an SSH client connects to your server, it will advertise that it wants to authenticate the host using a particular algorithm. As several are supported, OpenSSH simply generates one of each type. This allows your server to be identified with multiple types of fingerprints.
Taken from the OpenSSH man page, ssh(1):
When connecting to a server for the first time, a fingerprint of the server's
public key is presented to the user (unless the option StrictHostKeyChecking
has been disabled). Fingerprints can be determined using ssh-keygen(1):

    $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

If the fingerprint is already known, it can be matched and the key can be
accepted or rejected. If only legacy (MD5) fingerprints for the server are
available, the ssh-keygen(1) -E option may be used to downgrade the fingerprint
algorithm to match.

The files that end in .pub are not sensitive. They are transmitted to any client that attempts a connection. The files without that extension are the private keys. If those are disclosed, anyone will be able to impersonate your SSH server to any client. The private keys are used to prove to the client that the public keys being transmitted are in fact owned by the server.
When connecting to an SSH server, a series of events take place:

The SSH client connects to the server and advertises its preferred algorithm.
The server sends the desired public key to the client, if it is supported.
The client calculates the fingerprint of the public key.
For the first connection, the public key is saved to known_hosts.
For subsequent connections, the fingerprint is compared against the saved one.

On the first connection, the fingerprint is displayed to the user and the user is prompted to accept the fingerprint. This is known as TOFU, or Trust-On-First-Use. On subsequent connections, the fingerprint is verified silently and automatically. If there is a mismatch, the SSH client will refuse to connect and will warn the user that a MITM attack may be occurring. This behavior ensures that all future connections are genuine as long as the first connection is genuine. A MITM attack, or the SSH server changing its host keys for whatever reason, will invalidate this and require re-authenticating.
Which files do you need?
You do not need all three and you can remove any of them, but an SSH client will only be able to verify your server's fingerprint if it has a supported fingerprint stored in the known_hosts file. At a minimum, the RSA keys should be kept. Not every client supports ECDSA, and (EC)DSA has some security issues and is generally no longer recommended. There is no downside to keeping them all, though. A quick summary of the commonly available algorithms from a security perspective:

RSA is well-regarded and supported everywhere. It is considered quite secure. Common key sizes go up to 4096 bits and as low as 1024. The key size is adjustable. You should choose RSA.
DSA is not in common use anymore, as poor randomness when generating a signature can leak the private key. In the past, it was guaranteed to work everywhere as per RFC 4251, but this is no longer the case. DSA has been standardized as being only 1024 bits (in FIPS 186-2, though FIPS 186-3 has increased that limit). OpenSSH 7.0 and newer actually disable this algorithm.
ECDSA is newer and is based on DSA. It has the same weaknesses as DSA, but it is generally thought to be more secure, even at smaller key sizes. It uses the NIST curves (P256).
Ed25519, while not one you listed, is available on newer OpenSSH installations. It is similar to ECDSA but uses a superior curve, and it does not have the same weaknesses when weak RNGs are used as DSA/ECDSA. It is generally considered to be the strongest mathematically.


What is the process of finding deep links from an Android application?

A deep link is similar to opening a URL with an application in other operating systems. You can run firefox https://example.com to open that URL in your browser, and applications can tell the operating system that they can handle certain protocols (such as myapp://some/place).

In Android, the way to tell the operating system what your app can handle, is by using the AndroidManifest.xml file. This is explained in the documentation:
https://developer.android.com/training/app-links/deep-linking

To extract that file from an APK (Android Package), you used to be able to just unzip your.apk. These days, that will still work, but the XML is transformed into a binary format, so you need special tools to extract it. Most commonly, one would use apktool or aapt.

Taking F-Droid as example (I know it can open f-droid.org links):

$ wget https://f-droid.org/f-droid.apk
$ apktool d f-droid.apk
$ cd f-droid
$ cat AndroidManifest.xml
[...]
        <intent-filter android:autoVerify="true">
            <action android:name="android.intent.action.VIEW"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <category android:name="android.intent.category.BROWSABLE"/>
            <data android:scheme="https"/>
            <data android:host="f-droid.org"/>
            <data android:host="www.f-droid.org"/>
            <data android:host="staging.f-droid.org"/>
            <data android:pathPrefix="/app/"/>
            <data android:pathPrefix="/packages/"/>
            <data android:pathPrefix="/repository/browse"/>
            <data android:pathPattern="/.*/packages/.*"/>
            <data android:pathPattern="/.*/packages/.*/"/>
        </intent-filter>
[...]
        <intent-filter>
            <action android:name="android.intent.action.VIEW"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <category android:name="android.intent.category.BROWSABLE"/>
            <data android:scheme="http"/>
            <data android:scheme="https"/>
            <data android:host="play.google.com"/>
            <data android:path="/store/apps/details"/>
        </intent-filter>
[...]

We see that f-droid will open https://f-droid.org, https://www.f-droid.org, https://staging.fdroid.org, but a little further down we also find that it can also handle Google Play Store URLs. There are some more, but I'll leave those as an exercise to the reader :-). Look for the <data ... tags.


Is it possible for a hacker to cause hardware dysfunction?

The BIOS will probably have settings to change at what temperature your CPU or GPU shuts down or forces a machine reboot, and a sufficiently motivated attacker could flash new dangerous values from a running machine, then run some intensive programs to force them to overheat and permanently damage the hardware.  On most consumer hardware, I doubt it'd "blow up", but you'd be out some potentially expensive hardware.

Stuxnet is a well-known government-level malware that executed a more sophisticated form of this attack on nuclear centrifuges: it would override the safety controls display so that they appeared to be operating at safe levels, while simultaneously ramping up the centrifuge to a level at which it would break.


Is it safe to type a password in a VNC client connected to a server to access another server?

If the VNC connection is not encrypted, anyone on its path can capture and inspect the traffic. VNC uses the RFB Protocol (Remote Frame Buffer), and Wireshark, for example, already have dissectors for it, so don't count on it.
Some VNC solutions have proprietary plugins that add security (UltraVNC is one of those), but you don't need that. If you use a SSH tunnel to access S1, all traffic will be protected by SSH's encryption.
And I have way more trust on SSH doing encryption than a VNC solution.