Is this a safe way to identify someone through a QR code for a purchase?

I think you are protecting against your threat the wrong way, and I think you're also missing out on protecting against some additional threats.

Hashing vs encryption

First and most important: the end user's password should never be encrypted.  It should only ever be hashed.  Encryption is reversible but hashes aren't.  In the event of system breaches, you don't want someone to be able to decrypt an encrypted user password.  That could just be a simple matter of accidentally using the wrong terminology: its easy to confuse the two.

The goal

Before jumping in, it helps to reiterate the big picture: what are you trying to do here?  You are trying to make it easy for a kiosk to identify a user securely so that they can use a pre-paid account balance.

Breaking it down

The simplest solution would be to simply use the user's unique id to build the QR code.  This would get the job done very easily.  The problem with that (which your solution is trying to solve), is that the user id is probably guessable, so someone might easily figure out how to build your QR codes and start generating them for random user ids until they find someone with lots of money on their account.

Your use of the three piece identifier is designed to circumvent this problem.  The goal is to make it so that only the actual user is able to generate the QR code and use their money.  The issue I see is that you have used the user's password in the QR code generation process.  This has the benefit of making it hard for anyone other than the user to generate the QR code, but it has a big disadvantage of increasing the "surface area" for the user's password to be stolen.  Inherently, the more you use the user's password, and the more it transfers back from client to server (in any form), the more opportunities there are for a malicious user to steal it and use it to break into the actual account.  Granted, doing so would require understanding the form of your 3_piece_identifier and then doing a brute-force on the password, but such things are not outside of the realm of possibility, even if it isn't the highest on the list of concerns.

An important attack vector

However, your scenario doesn't protect against a simpler and much easier attack vector: simple replay attacks.  Nothing in your scenario ever causes the QR code to change, so if anyone could simply get a picture of the QR code created by the authorized user, that is all that would be necessary to pretend to be them in the future.  It could be as simple as literally taking a picture of someone else's phone while they have the QR open (maybe the person standing in front of you in line?) and then opening up that picture from your phone's gallery, and scanning the picture of the QR code when you checkout.  Unless the people running the cash register are paying attention (hint: they usually don't), you get to use someone else's balance with little effort.

One possible way to solve all of this

As a result, what you have isn't going to work (I don't think).  I think you should not bother using the password as part of the verification, and you need something to protect against replay attacks.  It can actually be very simple: when the user loads up the QR code on their phone they can hit up an API server-side to request a one-use key.  This will be generated server side, and it can even just be a completely random string: it doesn't have to include the user's email/id/password, but instead is simply associated with that user's account.  Make sure you and use a cryptographically secure random number generator, of course.  Make it nice and long (as long as it fits well in a QR code), make sure it is unique, store it server side associated with the customer along with an expiration time (no more than a couple minutes even), and then send it down to the client.  The client application turns it into a QR code, the employee app scans it, sends it back up, the server verifies that it is valid, that it hasn't expired, and can now bill the client's account properly.  As long as the API endpoint that generates the one-use-key requires a logged in user to work, everything should be nice and secure (or at least, as secure as the user's account is).  To recap:

User logs in
User requests to pay with the account balance
Client sends up request of single-use-key
Server generates (via CSPRNG) a unique single-use-key and stores it with the user's account, along with an expiration time
Server sends single-use-key back down to client
Client turns single-use-key into QR code
Employee app scans QR code and converts back to single-use-key
Employee app sends up single-use-key to server
Server verifies key's validity and can now charge the proper account

I would also be curious to see what suggestions other's may have.


Creating a 3rd party tool that requires a user's auth token for the service

Unless the server has configured to allow this use, you will probably be immediately blocked, in the browser, by Cross-Origin Resource Sharing (CORS). I've never completely understood the attack vectors CORS protects against, but one of them is the abuse of the same situation you're suggesting - access to a third-party site without either the third-party or the user's approval.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

To do what you are asking, within the CORS framework, the server would need to be an active participant. They would need to return the proper headers on a pre-flight OPTIONS request to support CORS for your site's domain.

For some sites, they may have configured CORS to be very permissive and then you could just sort of sneak in. But they'd have to leave the door open for you.

Another way they could willingly help you achieve this sort of interaction is to provide an API, with OAuth support. You could then use OAuth "implicit flow" to authenticate entirely in the browser, and you'd never have had access to their token. Implicit flow is somewhat less secure though... it's usually better to have a server involved in API calls with OAuth. In which case, you'd never have had their password, and your access to the API might be limited by the permission they gave you, but their browser wouldn't be holding the token they fetched for you to use.

If you want to do scraping from a site that is not a willing participant, you shouldn't be able to do it from a web browser without accessing their password or auth token. A desktop app might be the way to go.

If you want to be honest about it though, you could pitch your idea to Fanball.com and see if they'd open an API to you. You might be able to persuade them that your application would add value to their service.


Are SSL certificates from a CA necessary for secure communication?

Well, technically, if the user cannot confirm the identity of the certificate owner, then the communication cannot be really secure, because a villain may impersonate the server; he may even relay the data to the right server transparently (that's the man-in-the-middle attack model). Making sure that you talk to the right server IS an integral part of the security.


How to ensure integrity of program execution on foreign(someone else's) computer?

A priori, you can't.
There are several approaches you can take:

You just trust that the answer is right. Maybe you have no reason to doubt on the honesty of that remote computer. It's certainly easier.
You verify the result. Some computations require a lot of work (like, finding string which produces certain hash), but once you are provided a solution, it is cheap to verify that it is a solution to the problem (or if not exactly cheap, much cheaper than the original computation).
You can distribute the same work to multiple nodes, then verify they reach to the same solution. This "wastes" computing power in exchange of that extra trust on the results.
You distribute to several nodes a portion of the work. Thus doing a probabilistic audit of their results.
You trust the node results, but attribute the results to them so they can be blamed for errors

Please note:

Errors may be completely unintentional
Errors may be completely malicious, with an active effort to bypass whatever checks you may set
Your own computer may be the one in the wrong

A scenario where a host has faulty memory and provides bad results once in X blocks would be quite different than differences between two nodes due to hardware precision not being the same, and than people actively compromising the program execution to bypass a game license check.
In some cases maybe you could design the process in a way that allows such checks, Like having the remote computer process the data blinded with homomorphic encrption, in a way that it also produces a checksum that the controller may use for a quick check of the results.
could you use the Secure Enclave? Maybe. Signal conceived a way to show in a provable way the code they were using. It still needs to be able to run what you need (it's harder to program, and you have more limitations). Plus, it has the underlying assumption the Enclave itself isn't compromised (multiple vulnerabilities have been found).


How to safely allow upload of executable files

The most common solution for this kind of issue is to make sure the stored file is not accessible by the web server.

One simple way to do this is is to store the file in a database and never save it to the disk. You need to be careful not to create some kind of XSS though: do not allow the file to be linked to directly or, ideally, downloaded. If you need the file to be made available through your web interface, use the "attachment" content-disposition header to make sure the browser will not attempt to interpret the file.


Sharing a password for short term access to a shared resource

Your approach is right; while you want to keep just one account and share it with others for a while, the best way is to change password before-share and then re-change after-share.


How do arbitrary payloads execute on the remote machine?

Assuming you have located a buffer overrun (or equivalent), If the machine code doesn't match the language of the remote machine, then the expected result is that the application with the overrun will crash.

The overrun will operate as 'normal', trying to execute the code in your binary blob of a payload. The victim system will attempt to execute the instructions, but the instructions will not operate as expected for the target system - any given instruction will likely mean something different for the target system than the payload developer intended.  The victim system will, nonetheless, attempt execution.  Some operations may work perfectly fine. Some operations may be illegal instructions, potentially causing an exception or a crash.  Eventually, it is likely that the combination of instructions will either corrupt the running application beyond recovery, or outright perform a valid instruction under an illegal context, and the process will crash.


As it's in a security policy, most probably it is Information Security As a service. It is an outsourced service wherein an outside company handles and manages your security.


What Can I Do While I'm Waiting for "Chip and Pin" Credit Cards?

The first thing I would do is a full audit of any device you enter your card number into. Obviously you can't audit the POS machines at the stores you use, but if it was a store issue, they would have gotten a notice by now. So the problem is probably in the computer(s) you use for online transactions. I'd go to any machine you've typed your number into and run a full virus/malware scan on it. Being compromised by 2 separate sources in such a short time isn't entirely impossible, but still unlikely.

I wish I could provide more insight to a solution to prevent future compromises but I'm not privy to any technology that'll help here. I realize I didn't really answer your question, but I still think my suggestion is very much worth looking into given the lack of time between compromises. It would certainly be a top priority of mine if I was in this situation.


how about using OWASP dependency check tool to address Top 10 2013-A9-Using Components with Known Vulnerabilities

Yes, I have seen this tool as one of the dependencies before going to production in an enterprise level organisation.

I have to say that it's not flawless and requires quite the attention due to false positives. These false positives can be placed in an ignore file.

However, I think it's a nice "extra" to have before releasing a product to production.


Checking headers off a list is not the best technique to assert a site's security. Services like securityheaders.io can point you in the right direction but all they do is compare against a list of proposed settings without any context about your application. Consequently, some of the proposals wont't have any impact on the security of an API endpoint that serves nothing but JSON responses.

Strict-Transport-Security makes sense because it guarantees that users will directly connect to your site via HTTPS after their first visit and until the max-age timeout is reached - thereby preventing downgrade attacks. Even an API endpoint should be secured with SSL, so keep that header.
Access-Control-Allow-Methods: GET, POST, OPTIONS is not a security option per se. If your API works via CORS preflight requests you need to decide which methods you allow for cross-origin sites to use. Disabling CORS could make your API unavailable. If that particular setting is sensible depends on your implementation.
X-XSS-Protection: 1; mode=block can be good adivice for regular sites because it instructs the XSS Auditor (which is implemented in WebKit browsers but not Firefox) to not render the site when it detects a reflected XSS attempt. But for an API that just provides JSON responses and doesn't serve active content, this header doesn't bring any benefit.
X-Content-Type-Options: nosniff prevents browsers from making assumptions about the content type if the site didn't declare the type correctly. If you're running a JSON API you should serve the responses with Content-Type: application/json. If you do that correctly there will be no need to add the nosniff directive.
X-Frame-Options: Deny prevents any website from embedding your site in an HTML frame. That option stops clickjacking attacks where an attacker tricks users into interacting with your website through a disguised frame. But without interactive elements there is limited risk through cross-origin framing. Yet, as there are advanced attacks involving dragging content out of the frame which could disclose JSON responses, you might still want to leave that header there.
Content-Security-Policy headers control what kind of content from what origin your site is allowed to interact with  (scripts, stylesheets, images, etc.). Your setting "script-src 'self' means that only scripts from the same origin may be loaded. A CSP is useful for regular sites but doesn't make sense for your API endpoint because you don't serve any active content that could be controlled by the CSP.
The Server header specifies information about the server and the software running on it. It's often advised to not send that header at all to not disclose anything about backend software and versions.


It seems like someone wants to test your site for security flaws.

As you said

  linkredirect.php?site=www.ausetute.com.au&id=266%25%27//aND//%278%25%27%3D%273

is definitely a try for SQL Injection, %25%27%278%25%27%3D%273 is Hex value for %''8%'='3. You can try decoding the whole request in the form at bottom of this page.

Some attackers use the search engine to find interesting parameter names, using Google for this techniques is know as Google dorks. If you go through first few entries of this list, you can come to know how good the parameter id can attract attackers. Using different parameter name could help you from being away from bots/attackers who use above discussed technique.


How to choose a good (and easy to use) WiFi password?

Most good password advice (suggesting long passwords with characters randomly selected from a large character pool) will not ever go "out of date", except perhaps with regards to "minimum length" recommendations. (Used to be 8, then 12. Soon enough, if not already, 12 will be too short too. I recommend 15, preferably 20+.)

The problem you have is one that cannot be worked around without weakening the strength of your password, because strong passwords will never be very human-usable regardless of what interface you're using to enter them. The really strong passwords aren't even fun to enter on a full QWERTY desktop keyboard, let alone any of the more limited UIs available on "smart" devices of any sort. The best passwords aren't even human-memorable.

Unfortunately, that's just the nature of the beast. You can have a strong password, or you can have one that's easy to use and remember. Intersecting the two is nigh-impossible.

Some suggestions for your WiFi network:

Pick a PSK as long and random as your router will allow. You'll generally only have to enter it once per device, so you're getting solid protection for practically zero impact to your daily life.
Be very selective of who and what you allow onto your WiFi network. This saves you the headache of having to enter in the password (or talk someone through it) more often than you really need to, and reduces the attack surface of the network as well. Troy Hunt has a blog post on the subject that's worth a read.
Wire things up wherever possible. If something doesn't need to move around, it doesn't really need to be wireless. Again, this saves the headache of punching in the PSK when you really don't have to. It also helps network performance for the device you're hard-wiring (giving it higher speed & reliability), as well as the devices you're leaving on WiFi (freeing up airtime for them).


Remote code execution and XSS vulnerabilities. What steps should be taken to secure a server once these are discovered and patched?

The best solution would be to redeploy, but to answer your questions pointwise:

Ensure server is secure : Try and look for any rootkits,processes running that might have been setup to set persistance.
Ensure no data was compromised : Unfortunately, there is not sure way to do this as , data can be ex-filtrated very easily. You should always assume that data could have been ex-filtrated, if it is known that the server was compromised.
Ensure no malicious files were uploaded : This should get covered in the first point itself. If any non-php files remain on your system,it should not cause any problem. All what you can do at this point of time is to manually search for all php files , and decide if its malicious or not.

As you see the above tasks will take a toll !!Hence its recommended that you redeploy the solution!

EDIT 1:
This is only applicable for RCE.
In case of XSS point of view, as long as input is santized nothing needs to be done from server-side


What is the difference between `extendedKeyUsage` and an application policy?

In Microsoft terminology, "application policies" appears to be a custom extension with OID 1.3.6.1.4.1.311.21.10, which seems to be roughly similar in contents and goals to the standard Extended Key Usage. I see in an MS-produced certificate an "Extended Key Usage" extension which contains two OID, and an "application policies" extension which contains the two same OID, albeit each within an extra SEQUENCE layer, which probably means that the Microsoft-specific extension allows for some optional qualifiers. I could not find a public description of the extension. (Edit: this page says that the extension uses the "same encoding as szOID_CERT_POLICIES", which is 2.5.29.32, i.e. the standard Certificate Policies extension from RFC 5280.)

Given the lack of information on this extension, the best way to handle it is probably to ignore it altogether. The extension is not marked "critical" so you are allowed to ignore it if you do not understand it, as per X.509, section 4.2:

  A non-critical
     extension MAY be ignored if it is not recognized, but MUST be
     processed if it is recognized.


How can I find the malicious/backdoor codes without knowing the last modified date?

Unless you have an expert in computer forensics it's gonna be very difficult to know what happened, what files were modified, and what kinds of backdoors were installed.

Since your web server is "huge" I assume you're following a good backup policy, right? Right? Once you have a breach, assume the server is compromised and restore to the most recent good backup.


Getting remote access via path traversal for Java webapps

It is impossible to run executables with java if the code doesn't contain a line like :

Runtime.getRuntime().exec(variableProvidedByUser);

Now indirect exploitation of an upload vulnerability (given that the file type verification fails) is still possible if you know that the file is executed by a process other than java.

Keep in mind that there are applications that just BLOB files in databases so that executing the file isn't possible if the application doesn't explicitly do so or that java just reads using a byteStreamReader which will represent an array of bytes.

Another thing to keep in mind is that java runs in a virtual machine (JVM) and that java is a compiled language and that you cannot access user space in an arbitrary way nor simply uploading scripts and executing them.


I did not find anything on that page that describes Systrace as insecure.

Systrace was the result of groundbreaking research, described here:

Improving Host Security with System Call Policies, Niels Provos, USENIX Security 2003.

Later research reported vulnerabilities in system call monitoring tools (including Systrace):

Exploiting Concurrency Vulnerabilities in System Call Wrappers, Robert Watson, WOOT 2007.  blog post.

I do not know the status of those vulnerabilities.  I don't know whether Systrace has been patched to defend against those attacks.


My Yahoo accounts keep making random accounts for me on other websites. Why?

If you are uncertain whether your account has been hacked, you should immediately reset the password. If your account was hacked, some damage may have already been done, but setting a new password will prevent any further damage.

However, some sites allow you to create an account without first verifying your email address. This should not be alarming, and it is something that site should improve on their end. You can contact them to ask your account be deleted.

The better sites will require an email confirmation before someone can make an account with your email address. In this case you should simply 'not confirm' your account when they ask you to.

If your email account was hacked, though, the attacker may have already clicked the appropriate confirmation link. In this case you should contact the site owners and ask your account be deleted - since you did not make it yourself.

After the cleanup is underway, you should look at securing yourself. If you think a virus has caused the password to get out, then a professional machine wipe is the safest option. However, sometimes a password is accidentally leaked by phishing (entering your Yahoo password on a Yahoo-look-alike-fake-site), in which case you would not need a machine wipe.

As another answer just mentioned, using 2-factor authentication is a real boost in your security, but not a silver bullet.


Configure Windows Firewall Inbound Rule for Program Not Installed on Server

You need to find out which network ports your application uses to communicate. Usually, firewalls do not support to choose some programs. The standard is to define source, destination and ports.


How to securely store credentials in a bash variables?

Storing credentials in plain text is always a tricky case, it depends on case-by-case. The main rule is: never store the password inside the script.

If the script will run only manually (someone executing the script), do not store the password on the script, instead, make the script ask the password every time it's executed.

If the script will run automatically:

Create a specific user for the purpose you need. ensure the user has the minimum permissions as possible. Ensure the user does not have access to any other file and does not have permission to execute anything else other than the script you need.
Create a file containing the password and make the script read from this file. Make sure this password file cannot be read from anyone else.
Is passwords the only way to authenticate? Some applications support private/public keys. If you can, use it. Make sure the private key is secure.
Keep in mind that the chances of those credentials getting compromised are increased just by the fact you have them stored. Having that in mind, plan mitigation actions, for example, ensure the account has the minimum permissions as possible, ensure the account can only log in from a specific server, implement a log monitoring tool (or a SIEM) to get alerted when this account is used.

There's a very good article on the unix stack exchange about this topic, i do recommend you checking it out before implementing any script with passwords.


commercial CA for your client certificates?

Why do you need the client cert to be signed by a commercial CA?

This is needed for the server side since commercial CA act as a trusted third party for most client application since they have no way to check your public certificate authenticity otherwise.

Most often when using client-side authentication the authority is the organisation owning the server you want to authenticate to, and this is this organisation which will provide or sign you the required client certificates. In other words, if you want to connect to a server owned by company 'A', you need a certificate signed by company 'A' to proceed.

However, for some very specific use cases (some financial transfer protocols for instance) customers can come on board using certificates signed by a trusted third party, but in this case the company you want to connect to will provide you the list of trusted third parties you can choose from (Swift is the most common in this area, but there are a few others).


Are recent versions of ASP.NET implementing proper authenticated encryption?

FormsAuthentication.Encrypt() now uses the encrypt-the-MAC pattern over both the IV and the ciphertext, so yes, it is done correctly now.

As a side note, it does depend on the machinekey element to determine which encryption and MAC algorithms are used, it's worth double-checking your configuration to ensure you're configured to use either AES or Auto (which resolves to AES) and not DES (weak) or TripleDES (slow).


In order of inconvenience:

policy. Just tell internal users not to publish internal documents. If you can't do that, your problems are worse than leaky text. Whistleblowing, espionage and many other forms of data exfiltration are fundamentally HR issues.
password-protected PDF. Not much of a blocker but enough to put off accidental discovery should the files get leaked.
Adobe Content Server. Throw Adobe some dollars (quite a few dollars, actually) and they'll make it a bit harder to copy the PDFs using their DRM wrapper.

If you do all that and ban writable media, network connections, cameras, printers and pens from the environment, then there's only the employees' memory to contend with :-).


Faking a certificate check flow between 2 applications?

Quis custodiet ipsos custodes

In the case where one party is an executable and the other is a certificate, it is not possible to assure mutual verification - hence if A validates B and you need C to validate A.

If we were simply talking about 2 certificates, then mutual authentication is possible as signatures can be added to the entity without changing the signed part. Unfortunately x509 only permits a single signature on a certificate, and given that the trust model isn't really designed to work in this way, there may be complications with the tools to this approach (since at least one signing will require to be done with an unsigned certificate).

But I digress from the problem asked.

  A needs to be signed aswell

But for this to to have any value, the signature on A needs to be checked - hence C. And how do you validate 'C' - it's turtles all the way down.

...or at least till the point where it is out of your control, be that because you are constrained by the permissions configured by the admin or the trusted keys in UEFI or a root Certificate Authority (this does not mean that that your admins or hardware vendors or Certificate Authorities are implicitly trustworthy though).

It may be worth noting here that public PGP keys can have multiple signatories which, interestingly, would allow the OS to (within some limitations) validate the hardware as well as the hardware validating the boot OS in a Secure boot - but sadly "Secure boot" uses x509.


This is stored on the users device in a directory only accessible to your app. How do you store the API key for the user normally? If the answer is in plaintext then this is no less secure.

If you store the API key in an encrypted environment - say the keychain - then this makes that protection pointless.

If you are concerned set the cache control headers appropriately on sensitive requests. I.e.

  Cache-Control: no-cache, no-store


Did Google relax their SHA1 deprecation schedule?

Chrome 42 has now been released, and I can answer my own question: yes, they must have slowed down. 42 has the behavior that was expected in 41. I'm still not aware of any official explanation or acknowledgement of the delay.


The only way to make passwords stronger is to disallow weak passwords.  The reason a password is weak is that an attacker can guess it, not because of how you store it.

I've found http://www.passwordresearch.com to be a great resource for academic studies on passwords.  You may be interested in Designing Password Policies for Strength and Usability, which explores the effectiveness of policies on making passwords hard to guess, and how easy they are to remember.


Your basic idea seems sound, but I'd recommend using HMAC instead of a plain hash.  So the cookie sent to the client would contain three values:

user ID u,
timestamp t, and
authentication token HMAC(s; [u, t]),

where s is the secret key and [u, t] is a string unambiguously encoding the values of u and t.

An obvious disadvantage of this scheme is that there's no way for a user to explicitly log out.  Unfortunately, this flaw is inherent in any scheme that stores no per-user state on the server.  As you note, making the tokens valid for only a short period will help to mitigate this issue, although I'd consider even an hour a fairly long period for such a purpose.

If you can rely on the user's browser running JavaScript, you could include a script that sends a background AJAX request to the server regularly to refresh the authentication cookie.  This could let you reduce the validity period down to, say, a couple of minutes.


PRF stands for PseudoRandom Function.  A PRF will map input to output in a deterministic fashion (same input always maps to same output for same PRF) that appears indistinguishable from randomness to an attacker who doesn't know the internals of the PRF (and hasn't seen the PRF already process that exact same input, even if they've seen the PRF process many similar inputs).

Generally PRFs are taken at random from a PRF Family.  You can think of PRF Family as being a function taking an additional input (a random seed, also sometimes referred to as a random key) which selects a particular PRF (that maps input to output).  So if you have a 128-bit seed in your PRF family then there are 2^128 (340,282,366,920,938,463,463,374,607,431,768,211,456) possible PRFs that you could be using from that family.  This is contrast to hash functions, where there are only dozens of commonly used hash functions (MD5, SHA-1, SHA-256, SHA-512, etc).

Let's say you knew that "Hello" mapped to 8b1a9953c4611296a827abf8c47804d7 (in hex).  An attacker can quickly figure out that I'm using MD5 and could then generate outputs for any input they wanted.

However, HMAC - hash-based MAC is a family of PRFs.  So if you take the HMAC construction: H(K1 ++ H(K2 ++ m)), where ++ means concatenation, H is an ordinary hash function, and K1 and K2 are two keys which are defined to be derived from the same key using K1 = K XOR 0x5c5c...5c and K2 = K XOR 0x3636...36.  Now if I told you that my PRF (a HMAC using a particular key K) maps "Hello" to 53a7e60d93a6853780d622f3b5bd641f there would be no way for an attacker (who doesn't know K, but may know I'm using HMAC-MD5) to generate the output for an input they've never seen before.

The actual PRFs used in the IKE protocol are negotiated between the client and server.  The ones specified in the RFC for IKEv2 are HMAC_MD5, HMAC_SHA1, HMAC_TIGER (three HMACs generated from different hash functions), and AES128_XCBC.  In the original IKE RFC, the PRFs to use were not defined: "There are currently no pseudo-random functions defined.".

Note the difference between a PRF and a PRF family will often not be explicitly made.  In the literature you will often two inputs (a key, a plaintext) and generate one input.

In cryptography two related concepts come up - the PRP (PseudoRandom Permutation) and the PRG (PseudoRandom Generator).

A pseudorandom permutation (PRP) is a PRF that is one-to-one - that is a specific type of PRF where each output of the PRF (using the same key) can only be generated from exactly one input.  This allows one to invert the function and undo the effect of the application of its application -- thus you can apply the PRP (requiring knowledge of a secret key) to plaintext to create a ciphertext, and then apply the inverse of the PRP to the ciphertext (using the secret key) to decrypt it.  For example, a block cipher like AES-128 is a PRP -- it takes a block of input that is 128-bits as well as 128-bit key, and maps the plaintext block to a unique 128-bit ciphertext block.  Then these operations can be reversed to map the ciphertext block to the original plaintext block (using the inverse of AES-128 with that secret key).

A pseudorandom generator (PRG) is a function that emits a stream of bits that appears random based on some initial seed (e.g., a random key).  This bit-stream can be XORed with a long plaintext message to encrypt it (so the ciphertext appears random), and then you can decrypt it by XORing the PRG's bit-stream with the ciphertext.  One way to generate a PRG is to take a block cipher like AES-128, and use it in CTR mode.  That is you encrypt successive blocks incremented by one with the same key, and then concatenate the output together, e.g., PRG(K) = AES(K, 0) ++ AES(K, 1) ++ AES(K, 2) ++ AES(K, 3) ++ ... (where ++ means concatenation).


How find the hash creation method knowing password, salt, and resulting hash?

Decompiling the software is probably easiest.

Passwords are typically hashed with many iterations (like 100,000) of the hash function to slow down brute-force attacks that are trying to guess the password. Typically the server-side hashing code looks like this:

hashval = password

count = 0
while(count++ < NUM_HASH_ITERATIONS):
  hashval = sha1(hashval + salt)

return hashval

Depending on the software you are trying to break, you may be able to find the constant NUM_HASH_ITERATIONS in a config file somewhere, otherwise you'd either need to decompile the binary for it, or brute-force it. I don't know if off-the-shelf software exists to brute-force the number of iterations, but typical values, but it wouldn't be too difficult or CPU-intensive since you just try hashing it, and if it doesn't match, hash it again up to some limit like 1 million

hashval = "password"

count = 0
while(count++ < 1000000):
  hashval = sha1(hashval + salt)

  if (hashval == "3a58f2b..."):
    // We win!

that should run in a few minutes, and try it a bunch of times with different permutations for how the hash and salt are combined. Note that there are lots of things whose output looks the same as SHA1, so unless you know for a fact that it's SHA1, you may need to try those variants with MD5, SHA2-256, SHA2-384, SHA2-512, PBKDF2, BCRYPT, SCRYPT, ...


Client certificate common name? Subject alternative name?

What is used as subject in the client certificate depends on the context. If humans should be identified commonly an email address or a name is used. If machines should be identified typically the hostname of the machine is used. In the latter case it is probably best to use a subject alternative name (and maybe CN too) since a CN by itself does not express the type of the subject (i.e. DNS name, IP address, URL...).


Is there any way to tell if CCTV is on or not?

This would really depend on whether you care or not of being detected in the process and how much you're willing to invest into equipment, but sure. Provided there aren't some other, obvious signs the camera is on, such as the pan and tilt motors working

Low-tech approach: This is actually really similar to how doctors test patients for involuntary reflex reaction with a light source directed in patients' eyes and observing dilation (or lack thereof) of their pupils.Most well designed CCTV cameras would have what is called an Auto Iris (AI). Basically an automatic method of varying the size of a lens aperture, to allow the correct amount of light to fall on the imaging device. The lens would include a tiny motor and an amplifier, which are used to maintain a desired voltage video signal as produced by varying levels of light falling on its image sensor.By changing the level of light this camera's AI sensor receives, you could visually inspect the camera's iris movement even from an angle it can not record you (depending on its depth of field), or even audibly inspect the presence of such AI motor. Since these would be precision step (or stepper) motors, you would hear either a distinct buzz of it rotating, or the faint click when it's adjusted its step. Beware though, some ultra silent stepper motors have been developed already, tho I have yet to see CCTV cameras actually using them.Similar testing could be applied to other camera's components (e.g. auto-focus), with varying degree of how stealthy the tester could remain during this testing.
High-tech approach: This is easy and rather obvious - electronic bug detectors are capable of detecting compromising emanations (basically EMI: RF -> microwave -> IR fields in their descending wavelength / increasing frequency). Obviously they would all have some way of telling you which direction the compromising emanations are originating from, and most also at what specific frequencies and their exact strength.Such devices are getting fairly cheap nowadays, and you can buy pretty decently capable ones off local resellers for up to a few hundred dollars, or even a second-hand one for roughly a quarter of that price off online resellers. Since the choice is fairly good, I won't give you any links to specific products, not wanting to endorse any specific manufacturer.This detection would work both for wired, as well as wireless CCTV cameras. Wired CCTV systems would produce what is called a ballanced signal when on, which is a video signal that has been converted to enable it to be transmitted along 'twisted pair' cables, while the wireless (RF, or less common IR that require direct line of sight from the camera to the receiver) CCTV systems are even more apparent and would transmit higher energy radiation in their specified range (on top of compromising emanations from its internal circuitry).

Now, the other part of your question - detecting, if the video/audio feed is actually being recorded - is a bit more tricky to answer and would greatly depend on what system we're talking of here:

Analogue recording systems (rare nowadays) would actually add a bit more latency to the EM field emanating closed-loop when switched on (producing feedback spike in sine wave oscillation), basically moving the signal termination point a bit further on the power line (or separate signal cable, if not combined). This might, or might not be detectable by your equipment. Mind you, I do mean here only the exact moment when the recording device is switched on or off, and you would have a lot harder time detecting which state it's on, if it's in continuous mode of operation. Knowing the system beforehand and actually measuring its signal levels when on/off would obviously help.
Digital CCTV systems are a fair bit trickier to detect, if they're actually recording or not. In fact, you wouldn't be able to tell the difference between merely a receiver being on, or the recording system also doing its job that's connected to the receiver. With a bit of luck, you'd be dealing with direct-controllable IP cameras that would have a variable bit-rate (VBR) A/V feed encoder chip. This change in required bit-rate can be detected by better electronic bug detectors, but knowing the change in detectable EMI for the exact CCTV system beforehand would be of great help. With CBR/ABR (constant or average bit-rate) encoders, you'd most probably be out of luck though.

Now, I didn't write anything about disabling them, since you're not really inquiring about that, but maybe just a quick note that it's actually getting easier the more advanced they get, and with most new ones all you need is a decent pocket/torch size green laser (532 nm) directed for a few seconds directly into their CCD/CMOS sensor. The higher their resolution, the faster they will give up, depending also on laser's Watt rating, how much light diffraction are we talking of due to lens elements arrangement, their focal point, e.t.c. On wireless systems, you could actually detect their sensor's death by observing a sudden drop in compromising emanations intensity (camera's onboard video compression would be at its best with all the images of some framerate being the same, thus lowering the wireless frequency transmissions, i.e. lowering bandwidth).

Just mind, that CCTV cameras might be a whole lot more than cameras only, and pack audible and/or activity (movement / proximity / pressure change / presence of other  compromising emanations / ...) detection sensors as well. And the most funny of all (to me, as I wouldn't really care of being detected or not) is being highly equipped for any eventuality, but then unwittingly manage to disturb some wildlife (bats, birds, rodents,...) with your presence, that would fright and trigger the CCTV system's response for you.


If your friend's PC is infected with malware there is a risk that any file they transfer to you will also be infected. Using an up to date AV solution will minimise this risk, although it won't completely remove the risk as the AV may not find every piece of malware.

It is possible to segregate DropBox, yes - simplest route could be to use a VM and just run DropBox in that.


Self-signed CA and combining wildcard and SAN certificates

It is not a matter of wildcards. The behaviour you observe is due to the following: if there is a Subject Alt Name extension in the certificate, then the Common Name part of the DN is simply ignored. Said otherwise, the server names in the certificate should always be in a Subject Alt Name extension; the Common Name part of the subject DN is used as a fallback only if the Subject Alt Name extension is altogether missing (precisely, if there is no SAN, or if there is a SAN which contains no dNSName element at all). See RFC 2818, section 3.1:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

Therefore, in your case, you should put both mydomain.com and *.mydomain.com as dNSName elements in the SAN extension (the SAN extension can contain many DNS names). Whether names are wildcard or not does not matter at this level. As an illustration, have a look at the certificate used by Google (connect on https://www.google.com, then ask your browser to display the "certificate details"): this certificate currently features a SAN extension with no less than 44 DNS names, 34 of which being wildcard names.


Can information sent over unencrypted http still be seen if I'm on an encrypted wifi?

Your data would only be protected by WPA2 to the router. Beyond that, if it is not protected by TLS/SSL (HTTPS), your data was most likely sent in the clear. As for how much of a risk? Not much considering it is only used for haircuts. If someone had a network tap anywhere between the router and the haircut website, they could see your data in the clear.


I'm sure you don't really need that many plugins, as most have overlapping functionalities. As of early 2017, I recommend using uBlock Origin to block most ads and trackers, and if you are tech savvy you can add uMatrix (instead of NoScript). Take care to always use https when possible, but I'm not sure you need an addon for this.

The more you have plugins and extensions, the more you increase the attack surface of your browser. So please deactivate Flash, Java and your antivirus plugin. Your adblocker will do more than your AV plugin to protect you from malware. If you do need to keep a plugin, take care to keep it updated to its last version.


The ultimate success metric of a DoS attack is the loss of service. What is different about this type of DoS attack is that the control is in the attacker's hands: you limit how fast you read the server's response. So, yes, you get instant feedback that your attack is succeeding.

The answer to the question:

  Is traffic returned?

is, of course, "Yes." Returning traffic is required.

Google's full write up on the attack is here


Threat modelling - including threats one cannot mitigate?

While I think Jonah B covered things pretty well. Just to be more direct.

I would say "Yes", certainly.

Risks you cannot mitigate are as important as any other risk.

Residual risk is the important measure. This is the risk that remains after mitigation. You take all of the residual risks into account when working out the overall risk. Where there is no mitigation, the residual risk is the same as the initial risk.

Then, as Jonah says, you need to have an open discussion within the organisation about the residual risks and what they mean to the business. You also need to understand the risk appetite. How much risk will the organisation want to carry? This needs all organisational risk to be managed holistically of course.

UPDATE: Where should you stop? When the risks are irrelevant.

This also depends on who you are doing the modelling for. Senior and C-level people will only want the big ticket items that impact the business as a whole. Project Managers will want anything that could impact project delivery. Service managers want risks that will impact live running, SLA's etc.

If you are modelling a system change that will improve an organisations bottom line by $2m pa, you may be interested in risks that might have a monitory impact of a few hundred dollars in a year - unless they also have some other important impact such as customer trust or legal issues.

There is no single, one-size-fits-all solution for risk management.


Login details security using salt and hash, and a login role in postgresql

The most common pattern for web applications is for the application to authenticate using a role account, and then to perform user authentication against the database.  I would not grant individual user accounts access to the database -- consider the case where your database is inadvertently exposed to the internet.  Do you want user credentials to be usable in that case?  (It is slightly better in the case you've described, where they're derived from some PBKDF2 function.)

Your web application will require a role account in any case: it will need to register new users, retrieve the per-user salt for the PBKDF2 operation, and (depending on the application) need to perform operations for anonymous users.


Does UHF RFID implement any security at all?

The most common standard used for UHF RFID is EPC Gen2v2 (or ISO 18000-6C), also known as RAIN RFID. With the latest 'v2' iteration, the standard also includes security features including encryption of communication that are comparable to what you find in HF RFID standards.


Potential problem in public Maven repository

Codehaus was hacked, so repo.grails.org which proxies it, was filling up with the crap. We cleaned it up, tightened the checksum policy to fail the fetching if no valid checksum exists in the remote repo (codehaus) and enabled validation of the jar files integrity.


What would be reasonable approach for sandboxing new project to be protected against security holes made by chance?

If you're looking to run untrusted code on your system, then it does make sense (if possible) to sandbox the code, which reduces the impact of that code being malicious.

I'd say that running inside a Docker container as an unprivileged user is a good step.  If all you're worried about is inadvertant leakage of information then Docker is a reasonable fit, as it provides the running code an isolated environment so any leakage would not affect the underlying system (unless you had mapped that directory in from the host OS via Docker run's -v switch)


Why are HTTPS requests blocked by Firefox when using ZAP proxy?

ZAP creates certificates, on the fly, in the name of the site Firefox is going to.

Firefox is saying "I don't trust the CA that signed this cert", which is reasonable, because it's a MITM by an unapproved certificate authority.

You need to import Zap's signing certificate into Firefox's Trusted Roots Certificate Store.  If you Google "zap install certificate" you get lots of links to do so:

Adding SSL Certificates from OWASP ZAP - A Visual Walkthrough...
Setting up Zap for Browser
Intercepting HTTP traffic with Zaproxy

To quote the first link:

  Open up OWASP ZAP, go to Tools -> Options
  In the Dynamic SSL Certificates*, click on Generate if you don't see a certificate, else, Save the certificate in some location
  comfortable to you like your home folder.

...and then import it into your browser, using whatever process is appropriate, and which varies from browser to browser.  Should look something like this:

*In version 2.5.0.  Earlier versions may be just named Certificates.


Using a virtual machine for increased layer of privacy (w/ tor)?

If you create a more anonymous environment for your VM, then yes.  You can keep its software and browser plugins, etc, ... to a minimum and hence provide a more "vanilla" machine.

On top of that, if you'd prevent it from accessing the host machine, and sign in with a generic login (i.e: user and root).  Even when someone would compromise the machine, they'd have less information about the user using it.

If they compromise the machine completely,it's unlikely that they were to access the hosts' saved passwords, etc.  But it all depends on how well you keep both (or more) environments separate.


Is it sufficient to check if next starts with /, ie a relative link

No, it's not sufficient. Take this script as an example:

<?php header('Location: ' . $_GET['next']); ?>

An attacker could trigger an open redirect via redirect.php?next=//example.com/. You browser interprets this as an absolute URL using the same protocol.

  should I try to check if its a valid path in my application?

That would be the most secure solution. If checking valid paths is not an option, you should instead make sure the URL starts with /[a-zA-Z0-9] (that is one slash and one alphanumeric character).

Checking that it starts with / and not with //, as suggested by @BenoitEsnard, might be secure in some contexts but it's not always sufficient. Take this example (and ignore the obvious XSS problem for argument's sake):

<meta http-equiv="refresh" content="0; url=<?php echo $_GET['next']; ?>">

Here, an attacker could achieve a redirect via redirect.php?next=/%26sol;example.com/ which HTML-encodes the second / and wouldn't be picked up by a filter that checks for a // beginning.

The OWASP cheat sheet on unvalidated redirects has some additional advice.


Why would a password be hashed before being used to encrypt something?

It sounds like a primitive version of a key derivation function (KDF), in particular they probably could have avoided reinventing the wheel by using PBKDF2.

There are several reasons why you don't want to use the password directly as an AES key.

To distribute the bits. The main property here is that a hash function's output is, statistically speaking, uniformly distributed. People tend to pick passwords that aren't fully random, in particular, most passwords would only contain characters you can type in a keyboard. When used as an encryption key, a non-statistically random key may expose weaknesses in the encryption function.
To fit the keys to the encryption key length. Most passwords are going to be either longer or shorter than the key space of the encryption function. By hashing your password, the exact key length will be exactly the size of the input key of your encryption function. While the entropy of the derived key doesn't increase, this avoids the likelihood of exposing weakness in the encryption function if you just simply zero pad the password or worse truncate the password.
To slow down key derivation decryption. Per your description, the software is only using a single SHA256 round, which is not much. But with proper password based KDF, like PBKDF2, there are usually tens of thousands or hundreds of thousands of rounds of the underlying hash function. This slows down computing the keys, increasing the effective strength of passwords without increasing its length.
To keep the user's plain text password out of memory, thus preventing it from being accidentally dumped to disk during hibernation or crash dump. While this wouldn't protect the hash from being used to decrypt the data you're encrypting, it will prevent the password from being reused to decrypt other files (which presumably uses different salt) or being tried on your online accounts or other devices that you use.


Security of Firefox extensions such as Mailvelope

This question should be moved back to stackoverflow firefox-addon tag.

Yes an extension can get access to another, see this topic: https://stackoverflow.com/questions/22057888/controlling-a-firefox-extension-via-javascript/22099148#22099148

I'm not sure what you mean by "Can javascript from another page/tab that is open?"

Im also not sure what you mean by "Can another extension act as an MITM keylogger?"

Code of Firefox addons does not run in tabs, it runs in the whole browser scope, so it can access tabs, pages, and it can log keys, that come into the browser. You can make it log keys on the OS level with js-ctypes: https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Standard_OS_Libraries

An extension can modify the code of another, it would first look for the addon by the addons id, then it would unpack the xpi file if it is an xpi, then edit it, then repack the xpi. The changes will not take place until browser restart though. If the addon is not packed as xpi it can just edit the files in the folder, but again the code will not take affect till browser restart. OR if it's restartless until re-enable of the addon.


Using RSA with 3DES instead of plain 3DES. Does it make sense?

They said encryption of the whole data would cost more and is expensive (in term of performance).

This is correct. RSA, an asymmetric key algorithm needs a lot more computing power/time to encrypt/decrypt data compared to a symmetric key algorithm like DES/3DES.

Asymmetric key algorithms are usually used as a means to communicate a key for use in another symmetric key algorithm for data transfer.

For more information, see: http://en.wikipedia.org/wiki/Hybrid_cryptosystem

Basic example taken from wikipedia:

  To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following:

  1) Obtains Alice's public key.

  2) Generates a fresh symmetric key for the data encapsulation scheme.

  3) Encrypts the message under the data encapsulation scheme, using the symmetric key just generated.

  4) Encrypt the symmetric key under the key encapsulation scheme, using Alice's public key.
  Send both of these encryptions to Alice.

  To decrypt this hybrid ciphertext, Alice does the following:

  1) Uses her private key to decrypt the symmetric key contained in the key encapsulation segment.

  2) Uses this symmetric key to decrypt the message contained in the data encapsulation segment.

Perhaps as an improvement, your company would consider using AES instead of 3DES?


Why is it not recommended to permanently use the root account for all tasks?

You can consider this recommendation as a road sign that warns you about icy road. It does not prohibit you from driving fast. It just warns you that many people who drove fast had accidents. If you are a world champion in ice racing, may be you will just smile and drive further with the same speed. But for the most people following recommendation and reducing speed on an icy road will prevent them from accidents.
The same is about using root all the time.
You and some other people can be absolutely fine using root account all the time many years. But the most users are not as perfect as you are. Here are just a few examples why other people (not you) do mistakes:

... they are not fully focused on what are they doing, they are listening to music, talking to others, and submitting some commands in the shell
... they do typos and, for instance, pick up a wrong command from the history and hit Enter immediately, before they understood that it was not the command they wanted
... they are tired, but want to complete some task, work one or two hours more, and cannot precisely control every single command they issue
... their mental capacity is limited, they cannot take into account every single important factor that can affect particular command
... their knowledge is not complete, their assumption about how particular command works is not quite correct

In such cases issuing a potentially dangerous command without having root privileges may prevent from a lot of troubles.
You are right, even without being root one can make huge problems. But if one uses root account all the time, for the most users it leads to much more problems.


An application started by the root user has root privileges?

It depends on the actual server implementation.

While it looks like that node.js started as root will keep these privileges other servers (like Apache or nginx) only start as root and then give up privileges. A typical design for example is to have some master process which binds to the sockets with the necessary privileges and then forks a child which gives up all root privileges permanently before processing any data from the network. This is possible since the listen sockets are inherited from the parent process and the root permissions were only needed to bind the socket to a privileged port but not to accept connections on the established socket.

For example with nginx you will see something like the following:

$ ps -ax -o user,pid,ppid,cmd | grep nginx
root     14746     1 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 14747 14746 nginx: worker process
www-data 14748 14746 nginx: worker process

The first process shown is the master, running as root. The others are the workers started by the master running as non-privileged www-data. Only these non-privileged workers will process user input and thus in case of a compromise due to some unexpected input from the network only the non-privileged user will be compromised first. Of course, an attacker might then try to do a local privilege escalation using additional bugs in the host but that's a different issue.


What is a secure way to log onto the domain controller?

As your explanation, It is looks like a common issue in kerberos. It is call golden ticket attack.
You can take following step to mitigate risk of this vulnerability.

Use Least privilege mode
Limit Administrator access.
Use Administrator Account for Limited and required changes only.
Use End-point protection to mitigate attacks
Adding Additional Layer of Security to domain Controller. - You can configure terminal server and allow access to dc only from that particular server.
Based on Requirement you can decide kerberos ticket life time.
Server hardening with appropriate security policies , patches...etc.
Use Detection tool for further security.
Configure Host firewall such as windows Firewall.
Block internet access and internet browsing from Domain controllers.
Use Secured Domain management to avoid login to DC.


Online payment integration requires handling my bank credentials. Why?

Basically there must be technical reasons or business reasons Trustly doesn't support the pass-through transaction approval you're accustomed to.  Instead of asking their users to take action and passing them onto their bank to do so, Trustly prefers to automate this process and needs your credentials to act on behalf of you.  I won't say this isn't unusual, but it certainly isn't limited to Trustly.  Other financial organizations like Mint and Honeydue have used a similar model of requiring their customers' credentials for years.

There are technical alternatives that wouldn't require you to provide your credentials to Trustly, but like I said, there may be reasons they've chosen or been forced not to use them.  There's not a universal standard in banking for authorizing one party to act on your behalf with regards to querying account details or making transactions.  In fact, the EU has introduced a new standard (PSD2) to try to fix this compatibility issue and do away with the 'screen scraping' approach likely used by Trustly and others as a workaround.  If you want to read in greater detail about this change then you can start with this article: https://openbankinghub.com/screen-scraping-101-who-what-where-when-f83c7bd96712

Maybe the other organizations you've dealt with have been able to set up specific gateways for sharing data or transactions with partners, which is why they could redirect you instead of prompting you for your credentials.

Hopefully the USA or other countries still lagging behind will follow the example and push for standardization so trusting your credentials to third-parties is no longer needed.


You'll hear different arguments here but, at the end of the day, it comes down to how your system works in the real world.

It is certainly possible to build a system in which compromise of the database tier does not yield compromise of the application tier. You could imagine hardening against things like:

Injection of arbitrary data from the db layer does not cause a security issue in the front end (ie it assumes it will get back bad data)
Physical access of the db tier does not imply physical access of the application tier.
Infrastructure services (admin creds, share services for things like patch management, etc.) are isolated such that there is no way to island hop across.
The ability to push code to the db tier does not imply the ability to push code to the app tier.

...and so on.

So yes, it could be done. Pragmatically, very few apps work this way. I have seen very few in my career that could honestly say they have achieved this.

IMO, this is why people tend to not see this as super valuable, as very few apps are able to make this sort of security claim.


Why Same origin policy is based on host-name and not on IP?

It is very common to have multiple domain on the same IP address and often these domains are controlled by different parties. This is both typical for cheap hosting and for CDN like Cloudflare. Having the same origin policy based on IP address only would make cross-domain attacks possible. This would still allow using both IP address and hostname combined as restriction.

Additionally the same domain could be hosted by multiple IP addresses, for example with geo-specific IP addresses or with DNS based load balancing (i.e. round-robin DNS). Restricting the SOP to a specific IP address for the same hostname would lead to unexpected behavior, i.e. sometimes requests within the same hostname work and sometimes not. Thus, restricting the SOP additionally to the IP causes reliability problems.

This only leaves the SOP like it currently is, i.e. restricted to hostname but not IP address. Unfortunately this leaves it open to DNS rebinding attacks. But, assuming that the hacker does not control the DNS for the original hostname of a site, bypassing SOP with DNS rebinding only works if the target host does not properly check the Host header in the request, i.e. allows an attacker controlled hostname inside the request. Thus, this risk can be mitigated by properly checking the Host header at the server. It can also be mitigated by using HTTPS since the server does not have a certificate matching the attacker controlled hostname and the browser will thus refuse the connection.


Why infamous Addtrust certificate is still not expired (same private key) for code signing?

My understanding is that the Microsoft Code Verification Root (MCVR) is just used by the Windows kernel to decide whether a .sys driver file should be allowed to be loaded into the kernel.  I wrote a lot about this. I don't think it is useful for websites, because the MCVR does not appear to be in the "Trusted Root Certification Authorities" list on my Windows 10 computer.   You could check some other root certificate lists to get more verification of this.


Thanks @AndrolGenhald I think this is how the javascript works

log = e * 0.301029996;
if (log < 3) s = 0;
if (log < 6) s = 1;
if (log < 8) s = 2;
if (log < 10) s = 3;
if (log >= 10) s = 4;

Should someone have better indepth answer about entropy I will be eager to read it.


Many captive portals are a self contained httpd/dhcpd/router/whatever else (some routers have bittorrent clients but that is beside the point).  I don't think that this Wikipedia page disagrees with that.   The attack being discussed in the last part of this excerpt is referring to DNS tunneling.   If its a very large network,  such as a WISP, then they are going to need a dedicated HTTPD in order to handle the load and this might be on another network segment.  If their firewall rulesets are poor,  then it maybe possible to use DNS as way to access the open internet.


What are the consequences of disabling ssl v2 and weak ciphers?

Disabling weaker ciphers on the server can prevent older browsers connecting - which is the main reason this sort of thing is not kept as up to date as security teams would like.

Encouraging organisations to update browsers, and to require their customers to upgrade, is good practice and helps remove outdated versions and ciphers.


Things to check:

the secure_file_priv variable
The server must have read access to the whole path, and might need to have scan access also (e.g. to write in /a/b/c, you need r-- access to both a and b, and -w- access to c, at least. Those could be r-x and -wx respectively).


What is the name for this type of URL attack?

Server Side Request Forgery (SSRF) where the server makes a web request to a user controlled URL. MITRE has assigned this as CWE-918.


Bitcoins, and merchants which accept them, are inherently anonymous. It isn't exactly what you want, but it is an anonymous currency.


HeartBleed ReKeyed Cert with old creation date

From what I've found so far it's not possible unless the certificate is replaced with a completely new one and has a new creation date.

The only differences between the old and the new certificates are the lines that come after

Serial Number:
Modulus:
Signature Algorithm:

and the ---BEGIN CERTIFICATE--- ... --- END CERTIFICATE ---- part.


Is it possible to sniff windows smb logons and are they encrypted?

The NTLM challenge/response process does not transmit the passwords. If you want to get pedantic, neither the client nor the server has access to the passwords either.

Each has the NT hash of the user in question, which is used as the pre-shared key. Here's what happens when the client requests an SMB resource from the server:

The server issues a challenge.
Client encrypts the challenge using the user's NT hash as the key.
Client sends the encrypted challenge to the server.
Server encrypts its challenge with its copy of the user's hash.
Server compares the two encrypted challenges. If they match, access is granted.

The best you're going to get if you're sniffing that traffic, or poisoning with Responder, is the NetNTLMv2 hash, which is the encrypted challenge. You can then attempt to crack this offline, but as paj28 said, the only way you're going to get cleartext is using a tool like Mimikatz, which can read them from lsass.exe.


Should I have a maximum password length?

You should hash the passwords using a secure algorithm instead of storing it in clear text. The hash function will result in a constant output size regardless of the length of the input string.

Using a minimum length and perhaps some other quality rules is a good idea because it helps a little against laziness.

If you are afraid of Denial of Service attacks, you could put a server side limit for ordinary input fields into place, for example 1000 bytes. It's unlikely that someone wants to use such a long password.


Why can't persistence XSS be detected by a Web Application Firewall?

If you tightly adjust your WAF to your application so that it can fully distinguish valid from invalid input for specific input fields than you should be able to detect attempts to inject persistent XSS through the use of input fields.

But, usually WAF are not adapted that tightly to the specific application and in this case only employ some heuristics to detect common attacks. Apart from that persistent XSS can have different origins and don't even need to be added to the application by the use of input fields or even using the web interface at all. For example there was a stored XSS vulnerability within the amazon kindle store where the XSS was caused by script inside the metadata of the book description: Amazon.com Stored XSS via Book Metadata.


Metasploit SSH Error: could not settle on kex algorithm

Metasploit uses an SSH implementation written in Ruby which only supports the algorithms listed below.

https://github.com/rapid7/metasploit-framework/blob/b3c7fff32a62739241a223515574674b4a6b483c/lib/net/ssh/transport/algorithms.rb#L31

ALGORITHMS = {
  :host_key    => %w(ssh-rsa ssh-dss),
  :kex         => %w(diffie-hellman-group-exchange-sha1
                     diffie-hellman-group1-sha1),
  :encryption  => %w(aes128-cbc 3des-cbc blowfish-cbc cast128-cbc
                     aes192-cbc aes256-cbc rijndael-cbc@lysator.liu.se
                     idea-cbc none arcfour128 arcfour256),
  :hmac        => %w(hmac-sha1 hmac-md5 hmac-sha1-96 hmac-md5-96 none),
  :compression => %w(none zlib@openssh.com zlib),
  :language    => %w()
}

The server needs to provide a match in each category to create a secure connection.  Unfortunately, the Metasploit Ruby algorithms are considered weak by contemporary cryptographic standards, and newer OpenSSH server configurations disable them by default.

Metasploit would require additional Ruby code to implement newer algorithms.  The server, however, can enable additional algorithms in the sshd_config.  Modify /etc/ssh/sshd_config to specify compatible algorithms:

# Metasploit Client
KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256cbc,arcfour128,arcfour256
# Unsupported Ciphers from Metasploit: rijndael-cbc@lysator.liu.se,idea-cbc,none
MACs hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96
# Unsupported MACs from Metasploit: none

This will totally replace the server's algorithms with weaker ones.  A better solution would be to add the algorithms, or some subset, to the defaults.  Unfortunately, the configuration options require complete specification, so it is OpenSSH version dependant.  Defaults can be found in man sshd_config and then specified with the above options as additions.

For Fedora 22, it would be something like:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1


Is storing an encrypted zip file to an insecure cloud service an admissible way of securing privacy?

Privacy and confidentiality are different things...

A Zip file, even encrypted, is still there, and onlookers may observe not only the archive presence, name and size, but also the individual names and sizes of files within the archive, because these are not encrypted.

Traditional Zip encryption is weak and can be broken within a few minutes, regardless of how strong the password is — a good example of why homemade ciphers are an abomination. Some Zip-aware software can do better (e.g. with AES), but this may limit interoperability. For instance, Windows's explorer cannot open Zip archives encrypted with something else than the weak traditional stream cipher.

The normal, pervasive defence system of most people is to be utterly boring, thus making it unlikely that any potential attacker would bother trying to unlock their secrets. Yet, if you believe that an hostile adversary may actually try to learn your data and has access to your files stored in your cloud service, then you might consider making an unencrypted Zip archive, then encrypting that archive as a whole with GnuPG. GnuPG, among its many options, can do password-based symmetric encryption (with the -c command-line option) and does it reasonably well. The presence and size of the archive will still be known to eavesdroppers, as well as the archive file name, but archive contents, including individual file names and sizes, will be protected.


The easiest way I can think to do code injection in .Net web application is to allow file uploads, and allow the user to upload a Razor template file (.cshtml or .vbhtml), and allow the user to request/execute it.

As mentioned in the comments, the System.Reflection is also very powerful, and could theoretically be used to inject code.


There is Shamir's Secret Sharing algorithm, that allows to encrypt something in a way, that it can only be decrypted when a certain number of parts of the key are available.

You will probably need some additions for your voting system, as SSS is not a public/private key system.


Why is the issuer name field signed in X.509?

Everything in a certificate is signed. It is much simpler to sign the whole lot than to sign only parts of it; skipping the issuer name would not gain much anyway (the hashing part of the signature is really fast).

We can imagine a sort-of-X.509 with the issuer name being excluded from the signature; it does not seem, at first glance, to be terribly weaker, but this would deserve a lot of serious investigation to be sure of it. Since there is very little gain in excluding the issuer name from the signature, the exercise would be rather pointless.


Can people hack your iPhone Via Bluetooth if you leave it on?

Think about it. Your iPhone cannot know which Bluetooth devices you own. Therefore it displays all devices it can see. That is perfectly normal. But there will only be a connection if you, personally, connect to that device. So your neighbour cannot connect his device to your phone without you knowingly doing it.


What's the difference between using duckduckgo with !google bangs and using google directly?

There's no difference: DuckDuckGo doesn't offer any privacy protection when redirecting the search to another result page with a !bang. E.g. !google foo (https://duckduckgo.com/?q=!google+foo) just redirects to https://google.com/search?hl=en&q=foo using both

meta refresh

<meta http-equiv='refresh' content='0; url=https://google.com/search?hl=en&q=foo'>

and JavaScript

<script language='JavaScript'>
    function ffredirect(){
        window.location.replace('https://google.com/search?hl=en&q=foo');
    }
    setTimeout('ffredirect()',100);
</script>

...but not with an actual HTTP redirect, probably in order to hide itself as the referrer:

<meta name='referrer' content='never'>

On the other hand, it prevents Google from getting direct information on the keystrokes and typos through Ajax queries:


Network scan across multiple subnets and output list of names and IP's

The nmap tool combined with some scripting would definitely be able to do this.

Read the nmap book Chapter 13. You might find the "grepable output" is of use:
https://nmap.org/book/output-formats-grepable-output.html

This chapter even gives ideas for cutting the file into different fields.

Scanning multiple subnets is straightforward. You can feed nmap an "input list file" or you can specify multiple targets on the command line:
enter link description here

As another poster noted; it'd be helpful to see what you've tried already.


Trail of passwords for major websites over the internet

Since the generalization of HTTPS, most sites rely on the SSL/TLS encryption between the client and their site. Then as you said they only store a hash of the password. It is true that between the SSL endpoint and the actual processing, the password is in clear text, but it is assumed to be the same security zone.

In the older days (only HTTP), two ways had been used, none of which were perfect.

Digest variant of BASIC authentication.

The HTTP protocol has provision to transmit credentials in header fields, the so called basic authentication. The user name and password are combined with a single colon and encoded in a variant of Base64. And can be stolen by anybody able to access network data.

To add some privacy, people imagined to only send a hash of the credentials. This was the digest authentication specified in RFC 2617. In this mode, a hash (MD5) of the credentials combined with a nonce given by the server is transmitted. As MD5 is non invertible, an attacker cannot steal the original password. But the major drawback is that the password must be maintained in an invertible form on the server.
Javascript encryption of login forms

This is mainly a variant of the former for login forms. The credentials are hashed client side, normally with a nonce transmitted in a hidden field. Here again the passwords must be kept on the server in an invertible form.

As it is now generally accepted that it is more secure to exchange the plain text password over a secure line that only a hash on an insecure one, those two ways are no longer really used.


What are the main weaknesses of mobile software based OTP generators?

Kind of a vague question, but off the top of my head:

Leaving protection of the key/seed to the mobile device means that its possible to extract the key on various platforms unlike dedicated hardware devices with protected storage
You lose your phone you lose your key


What parameters define information sensitivity?

Sensitivity of data is determined by the data owner who is responsible for classifying the information and also liable in case the information gets compromised. So no matter if data is used by human resources department or marketing, the classification will stay the same. The relevant metric for estimating the sensitivity is closely related to the cost of the data, id est:

the necessary effort to reproduce the data if lost
the financial cost of acquiring the data initially
the reputation loss in case of a successful incident
the intellectual property that might get infringed

All these metrics vary in gravity according to the institution. For example R&D data is hard to reproduce, impossible to rebuy and you lose intellectual property, so it should be classified as confidential. The reputation loss plays a minor role. When patenting is over, the classification will be much lower.


Is there any benefit to keeping a VeraCrypt file container inside another VeraCrypt file container?

I'd say it is not worth the trouble. Inserting an additional layer of encryption may thwart the work of an attacker only if he's trying to bruteforce the password, but won't be effective against several side-level attacks (cold boot attack, evil maid attack, malware, etc.). Plus, it will lower dramatically I/O performance as everything needs to be encrypted/decrypted twice.

It would be better to use VeraCrypt in the standard way, concatenating the two strong passwords into an unique, stronger password.


In Oauth what is the benefit of the access token being opaque

In OAuth, or any other protocol where the token can be opaque or transparent, the benefits and risks swing based on what your desired result is:

If you want the client to be able to parse the access token, you need the token to be transparent.
If you don't want the client to be able to parse the access token, you need the token to be opaque.

Indeed, this is the definition of opaque and transparent tokens; the client can see into them, or not.

If your token is transparent, you must sign it, otherwise, anyone could simply edit your token contents, and claim anything they want.

So, the first obvious benefit of having an opaque token is that you can just throw away any signing mechanism; you don't need it, and conversely, if you have a proper transparent token, the client can read the token, but not edit it.

Another benefit of having an opaque token is it is more secure; No encryption method is truly random (i.e., there must be a way to decrypt it), meaning you can always tell which encryption protocol is used if you can read enough of the contents of the tokens (transparent tokens).  This itself reduces the time to identify your cipher (knowing the protocol).  Many people don't think this is very risky, and indeed, if you use more than 80 bits of entropy, they are right (10 truly random characters for your cipher, i.e. "secret key").

However, and this is much more of a risk; transparent tokens allow crackers to play with the contents (because they see them), and some protocols have serious weaknesses that allow you to create collisions or even decode the cipher in a much shorter period because the cracker will know the protocol as well as the contents of valid blocks (most encryption protocols use 16 byte-long blocks, so if your token contains 160 chars of data, you've given the cracker 10 valid combinations to your cipher. This decreases the time it will take for them to identify your cipher by an order of magnitude.  Giving them more transparent tokens will further reduce this time as well.  Some protocols have a reduced version of this risk, but by the nature of what encoding is, having the encoded block, and decoded block both in your hands, you're always going to make it easier to break.

This is why many choose opaque tokens.  Indeed you should always opt for opaque tokens if there is no need for any external entity to be able to parse your token.  An example of this is a service framework in which you only pass the token to the service as a blind claim; you have no idea what it says, but you know it works and identifies you.  It is only up to the service to confirm it's you via the secret key or cipher.

Opaque tokens also don't require signing, which I mentioned above, they also don't require divulging anything about chosen protocols.

For this reason, they are much more secure, not only mathematically and logically, but get rid of human implementation errors, which is, to be honest, 99% of the reason cracks are ever made in the first place.

Interesting note

Even true randomness means a 36.7% loss (1 divided by e) of combination space when randomly guessing. This means a 1000 possibility combination lock, if guessed randomly, actually has a 1 in 630 chance of getting it correct.

So 1 / e is the absolute best chance you have, and that is pure random.

Any "possibility" that is interesting to a human, "information", is not truly random by definition, and worse, any protocol that is used to decode it, gives up some possible space for the cipher by the way the protocol works.  So, in reality, your chances of randomly guessing an answer is significantly smaller than the entropy or combination space most people talk about or think they actually have; it's usually, when all accounts are measured by a good hacker, at least one order of magnitude easier than a layperson thinks.


Applies, but was forgotten in spec.

Judging from the IETF mailing list it was forgotten inside the RFC document.

Relevant mail is the second in the thread:

  Good point.

  DTLS is intended to support extensions--and OpenSSL, at least,
  supports them in the same way as it does for TLS.

  There probably should be a definition of ExtendedClientHello
  in 4346 and 6347, but it's exactly the PDU you would expect.
  I.e., the extensions come after the CompressionMethod.

  -Ekr

Full thread

There is a nicely rendered thread on GMANE. And the individual posts are as follows:

[TLS] DTLS lacking TLS extensions ?, Martin Rex (Archived here.)
  Re: [TLS] DTLS lacking TLS extensions ?, Eric Rescorla (Archived here.)
    Re: [TLS] DTLS lacking TLS extensions ?, Martin Rex (Archived here.)
      Re: [TLS] DTLS lacking TLS extensions ?, Marsh Ray (Archived here.)


How does a CSRF token prevent an attack, and how can I safely use/avoid it for my JSON API?

A summary of how CSRF attacks work goes like this:

You, the good user, while logged into a web site A, visit some other site's page B.
That page does a GET (can be a POST, a little more complex to set
up) to a page X on site A (which you are logged in to), with e.g.
. Your browser obliges, using your already authenticated session/cookie
Page X by design causes change in state of your account -
classic examples are "transfer X dollars to B" (less realistic) or
"set user status line to PWNED" (more realistic)

There are a number of ways a CSRF token can be implemented, but the idea is that a simple GET request to a state-changing URL X will not work unless an additional changing piece of information (the token) is included, e.g. it has to be "X?token=123123213". Since the token changes reasonably often, the step 2 above will not work. The would-be attacker does not know the current token.

Your question 1 - the attacker does not see the content of the page X, he only forces you to visit it.

Your question 2 - since this is all about actions when already logged in, it is more or less ok to not use CSRF protection on the login page. There is a chance that you can be forced to log in as someone else and not notice it, though.

http://en.wikipedia.org/wiki/Cross-site_request_forgery

A more general class of issues is http://en.wikipedia.org/wiki/Confused_deputy_problem


Is there a Security/Privacy risk in storing computers' hardware thumbprint?

For its computations related to activation keys, Microsoft must perform a delicate dance between a number of booby traps. In particular, they aim at detecting people who reuse the activation keys on other systems, but not unduly block users who simply changed parts of their hardware. There is a fine limit between "this is a new computer" and "this is the same computer but with some upgraded parts".

Among Microsoft's preoccupations, I'll wager that "user privacy" ranks rather low. However, "user sues Microsoft because of privacy issues" is probably more of a concern, from Microsoft point of view, so chances are that they will make some token public relations effort on the lines of "your privacy is important to us" and collecting only 10 bits of a MAC address may be part of this apparent display.


Methods for allowing restricted access to web applications

I would suggest more VPN as some inside-webserver solution. The reason is, the problem of the authentication and encryption belongs to this specific software, while webservers have to fulfill a lot of other criteria, too. Calculating the working hours / security I would vote a VPN solution.

You have to solve 2 tasks:

authentication
encryption

Although the authentication part can be made also in the webserver. In this case, we can see the 3 points of the authentication:

what you are
what you have
what you know

I suspect you don't have too much control over your users, and over their systems. Thus (1) falls out. You can think on (2), i.e. on some hardware key-based authentication. In the case (3), you can use either the good old passwords, or some more tricky way (for example: one time password sent by sms).

On the encryption side: the VPN solves it. On HTTPS, it is not so easy. Use strong encryption algorithms with properly configured and authorized certs.


FIN Scan: sneak through certain non-stateful firewalls?

TCP FIN exploit a subtle loophole in the TCP RFC to differentiate between open and closed ports. Page 65 of RFC 793 says that "if the [destination] port state is CLOSED .... an incoming segment not containing a RST causes a RST to be sent in response." Then the next page discusses packets sent to open ports without the SYN, RST, or ACK bits set, stating that: "you are unlikely to get here, but if you do, drop the segment, and return."

This is indeed an old way to circumvent packet filtering, and the industry has made this scan (mostly) obsolete. Like any other scan, the idea is to try it and see if this works, and compare with other scan type to understand if a port is really close or open.

  When scanning systems compliant with this RFC text, any packet not
  containing SYN, RST, or ACK bits will result in a returned RST if the
  port is closed and no response at all if the port is open. As long as
  none of those three bits are included, any combination of the other
  three (FIN, PSH, and URG) are OK. Nmap exploits this with three scan
  types:

  Null scan ( -sN) Does not set any bits (TCP flag header is 0) FIN scan
  (-sF) Sets just the TCP FIN bit. Xmas scan ( -sX) Sets the FIN, PSH,
  and URG flags, lighting the packet up like a Christmas tree.

  These three scan types are exactly the same in behavior except for the
  TCP flags set in probe packets. The key advantage to these scan types
  is that they can sneak through certain non-stateful firewalls and
  packet filtering routers. Such firewalls try to prevent incoming TCP
  connections (while allowing outbound ones) by blocking any TCP packets
  with the SYN bit set and ACK cleared.

Source: Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning


Will disabling WebGL make me more or less unique on the internet?

Panopticlick is not a comprehensive browser fingerprinting analysis tool. In fact, it is pretty poor and only exists to raise awareness about fingerprinting. For example, it doesn't do the extensive WebGL fingerprinting was touched by recent research papers. Because of that, it does't take into account the fact that WebGL can be used to identify an individual system with nearly 100% accuracy, effectively bringing your anonymity set down to exactly one individual: you. The same is true for techniques such as AudioContext fingerprinting, which Panopticlick likewise does not use. This behavior results in the site mistakenly concluding the disabling WebGL decreases your anonymity set.

Browser fingerprinting is a complex topic, and no one service can tell you exactly how unique your system is. Currently, the most effective way to mitigate browser fingerprinting is to use the Tor Browser, which strives to have a uniform fingerprint among all its users. It will disable features that can potentially allow cross-browser fingerprinting, such as AudioContext fingerprinting and WebGL fingerprinting.


Is there any security concern if I sent the security token, issued from a trusted IdP, to javaScript?

I see two possible attack vectors.

eavesdropping
cross site scripting vulnerabilities in your web application

When the token isn't transmitted via HTTPS, it can be intercepted and used by an eavesdropper. To prevent this, enforce https for all communication.

When the HTML document includes any data from a 3rd party, you need to be weary of XSS injections. When an attacker is able to smuggle JavaScript code into the page which is executed, it can access any data in any JavaScript application embedded in that HTML document and send it to any other website. To prevent this from happening, make sure that all your web applications sanitize any user-provided strings properly. You might also want to inform your users that your website does not have any hidden features which can be unlocked by entering some cryptic codes into the developer console (like Facebook does, for example).

Also keep in mind that you can not prevent the user from finding out about their own token. When you need to protect the token from being discovered by the user it is issued to, you will need to find a different solution.


How to execute a command directly on the host system through docker.sock in a Docker container?

The best way that I've found to execute commands on the underlying host with an exposed Docker socket is Ian Miell's most pointless docker command ever

The command looks like this :-

docker run -ti
    --privileged
    --net=host --pid=host --ipc=host
    --volume /:/host
    busybox
    chroot /host

and will essentially drop you straight into a full root shell on the underlying host.

To break the command down

--privileged will remove the default Docker security layers like Apparmor and capability restrictions.

--net=host --pid=host --ipc=host runs the process in the host's namespaces instead of a separate set of namespaces for the contained process.

--volume /:/host mounts the host root filesystems as /host inside the container

then

chroot /host as a command changes the root to that /host directory.

If you're running via Kubernetes, you can use The most pointless Kubernetes command which effectively does the same thing (assuming the cluster doesn't have a restrictive Pod Security Policy in place).


Penetration testing Windows Phone 8 apps w/o source

I believe it is possible to jailbreak a windows 8 phone.  Seeing as Microsoft can't keep people from pirating games for the XBOX 360, I don't expect Microsoft to be able to put up much of a fight in the jailbreak war.

A jailbroken device isn't the only way to conduct analysis of a mobile app. You can decompile Windows 8 apps  which can shed light in their inner workings.  As with iOS and Android hacking,  you can MITM SSL/TLS connections by importing an your own certificate and intercept requests using a program like BURP.


Can I use a single SSL cert on two different servers?

If the master and slave use the same hostname, or you have a wildcard certificate and they both use subdomains of the same domain, then there is no technical reason why you can't use the same SSL certificate for both. But some SSL certificate issuers license them per server, and you may be in breach of your licence conditions.


Should things like project IDs, cloud region IDs etc be kept secret on an open source project?

Assuming that the underlying cloud providers are secure (meaning that they don't leak information from the IDs, or grant unauthorized access to change the project settings that they refer to), there's generally no real problem with the IDs being committed.  They disclose the fact that a service relationship exists, nothing more.  Of course, the rest of the code that interfaces via those IDs would also disclose that the relationship exists.

However, committing the logging email addresses is an issue.  If those email addresses are leaked, and there's enough information committed around them to reconstruct the form of the logs, it increases the risk of processing if the sender of the logs doesn't properly sign them with DKIM or such, and/or if the recipient doesn't verify that signature before acting on them.  Note that you can't really trust email logs without verifying them, regardless; because email addresses are also subject to receiving unsolicited and unwanted messages, you could end up processing some email of an improper form if you're not careful.  The probability of having to deal with such also goes up when you commit the email address into a public repository.  (If you want to test your ability to properly handle undesired submissions to that email address, by all means.  But you could also test that by sending to that email address from unapproved submission email addresses as well.)

As always, the ultimate decision to do such should be firmly rooted in your security policy, which is necessarily based on your threat assessments and mitigation strategies for those threats.  Anybody here can only express their thoughts based on their own understandings of the issues involved, and nobody here has any idea what your threat mitigation strategies are -- or even what they should be based on information that only you have.  Make wise decisions, which almost certainly don't include "accepting and acting on the word of random StackExchange members with no additional critical thought".


How Can Phone w/ No Internet Service Get Downloads? (Hacked??)

Even if you don't have a plan which includes mobile data your phone has still the physical ability to get these data, both via mobile data or by Wifi.
Since updates to the phones operating system are usually pushed directly by your telecom provider you don't need a plan with mobile data to receive such updates. And even if you have switched off mobile data completely you are probably still be able to use Wifi.


What if the Google account login screen is spoofed

It's called phishing, and no, 2FA doesn't prevent it in most cases (but you should still use 2FA). This sort of attack is why people recommend to always look at the browser's address bar before typing in a password (though that's had its own issues). When logging in through a local application though, you just have to trust that application to not steal your password. If you don't trust it, don't run it.

The only type of 2FA I'm aware of that can prevent this sort of attack is Webauthn and U2F, but this is only applicable when logging in through a trusted web browser. With a local application, all bets are off.