Client-side hashing of password before sending it from login form

From the attacker's standpoint, whether you send a plain text password or a MD5 hash or it doesn't make much difference, as long as sending the same value over again unlocks the door. Remember, getting in is the primary objective, not obtaining the exact value of the password. So if the attacker intercepts the hashed password, sending it again from his box produces the same result -- login accepted. Using HTTPS would be the best solution, as it protects all the data.

EDIT: As for the situation when your application will be accessed over plain HTTP -- well, you are screwed then. Unless you roll your own protocol (NOT RECOMMENDED) to encrypt the password client-side and decrypt, hash, and validate it server-side, the password will be exposed.


How do I get the list of cipher suites supported in a specific TLS version?

Yes, the documentation you are looking for are the RFC documents for the various versions.
Here are the links to the RFCs for TLS 1.0, 1.1, 1.2 and 1.3:

TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

Since this would be a link-only answer, here the core of each RFC.
TLS 1.0
The chapter 9. Mandatory Cipher Suits reads the following:

In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

This means that, unless and application profile says otherwise, a compliant application only has to implement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be compliant to TLS 1.0. Of course, more ciphers were defined by TLS 1.0, and implementations were free to include even more, but to be TLS 1.0 compliant, this was the absolute minimum.
A complete list of all TLS 1.0 standardized ciphers is found in Appendix C. CipherSuite definitions:
CipherSuite                      Is       Key          Cipher      Hash
                             Exportable Exchange

TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL
TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA

TLS 1.1
Similarly to TLS 1.0, TLS 1.1 defines in chapter 9. Mandatory Cipher Suits the following:

In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Again, the complete list of all standardized ciphers is found again in Appendix C. CipherSuite Definitions:
CipherSuite                           Key Exchange   Cipher      Hash

TLS_NULL_WITH_NULL_NULL               NULL           NULL        NULL
TLS_RSA_WITH_NULL_MD5                 RSA            NULL         MD5
TLS_RSA_WITH_NULL_SHA                 RSA            NULL         SHA
TLS_RSA_WITH_RC4_128_MD5              RSA            RC4_128      MD5
TLS_RSA_WITH_RC4_128_SHA              RSA            RC4_128      SHA
TLS_RSA_WITH_IDEA_CBC_SHA             RSA            IDEA_CBC     SHA
TLS_RSA_WITH_DES_CBC_SHA              RSA            DES_CBC      SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA         RSA            3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_DES_CBC_SHA           DH_DSS         DES_CBC      SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      DH_DSS         3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_DES_CBC_SHA           DH_RSA         DES_CBC      SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      DH_RSA         3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA          DHE_DSS        DES_CBC      SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE_DSS        3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA          DHE_RSA        DES_CBC      SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE_RSA        3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5          DH_anon        RC4_128      MD5
TLS_DH_anon_WITH_DES_CBC_SHA          DH_anon        DES_CBC      SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     DH_anon        3DES_EDE_CBC SHA

TLS 1.2
Chapter 9. Mandatory Cipher Suits again tells us the minimum required supported ciphersuites for TLS 1.2:

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

The complete list can be found again in Appendix C. CipherSuite Definitions:
Cipher Suite                            Key        Cipher         Mac
                                        Exchange

TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL
TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5
TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA
TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256
TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5
TLS_RSA_WITH_RC4_128_SHA                RSA          RC4_128      SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA          3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA            RSA          AES_128_CBC  SHA
TLS_RSA_WITH_AES_256_CBC_SHA            RSA          AES_256_CBC  SHA
TLS_RSA_WITH_AES_128_CBC_SHA256         RSA          AES_128_CBC  SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256         RSA          AES_256_CBC  SHA256
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS       3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA       3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS      3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA      3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5            DH_anon      RC4_128      MD5
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon      3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS       AES_128_CBC  SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA       AES_128_CBC  SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS      AES_128_CBC  SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA      AES_128_CBC  SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon      AES_128_CBC  SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS       AES_256_CBC  SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA       AES_256_CBC  SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS      AES_256_CBC  SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA      AES_256_CBC  SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon      AES_256_CBC  SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256      DH_DSS       AES_128_CBC  SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256      DH_RSA       AES_128_CBC  SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256     DHE_DSS      AES_128_CBC  SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256     DHE_RSA      AES_128_CBC  SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256     DH_anon      AES_128_CBC  SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256      DH_DSS       AES_256_CBC  SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256      DH_RSA       AES_256_CBC  SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256     DHE_DSS      AES_256_CBC  SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256     DHE_RSA      AES_256_CBC  SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256     DH_anon      AES_256_CBC  SHA256

TLS 1.3
TLS 1.3 is a bit more demanding with minimum requirements. Chapter 9. Compliance Requirements again states what an application needs to implement at minimum to be compliant to TLS 1.3, but it's more than a single cipher suite.

In the absence of an application profile standard specifying otherwise:

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement theTLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites (see Appendix B.4).

A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519.

Furthermore, chapter 9.2. Mandatory-to-Implement Extensions lists many mandatory extensions that a TLS 1.3 compliant application must implement. These are too many to list here, but the RFC is linked at the top of the question if you want to see those yourself.
Finally, the Appendix B.4 Cipher Suites defines the following Cipher Suites:
+------------------------------+-------------+
| Description                  | Value       |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
|                              |             |
| TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
|                              |             |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
|                              |             |
| TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
|                              |             |
| TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
+------------------------------+-------------+

As you can see, this list has been reduced quite a lot. Turns out supporting a ton of cipher suites with questionable security is not a great idea.


Communicating routed interfaces for Cisco ASA 5506-X

Disclaimer: without you posting your config in here it's quite hard for me to help, however, I will attempt to give you an idea of why this might not be working.
Firstly, as you've stated by design you cannot ping an interface if you come from another interface on the same device, this is a security feature of the ASA and it is fully intended to be like this. This is whats known as a "Distant interface". If you think about it, it is a good thing you cannot ping between interfaces, realistically you wouldn't want such a thing even if you think you do. I would like to add this can not be disabled.

Secondly, without altering your access rules you will not be able to achieve this, there is a simple reason for that. The ASA has something called the Modular Policy Framework this is what is essentially stopping this operation from taking place. By default, the MPF will not inspect ICMP traffic. In essence what this means is you will not be able to ping or traceroute from the inside to the outside. There are two ways you can achieve this:

Inspecting ICMP
Access rule to allow ping replies

By inspecting ICMP traffic this would subsequently allow this function. Alternatively, you can add an access rule to allow the ping replies back in. Ideally, you would want to choose the first one as it is more secure. If you're not inspecting ICMP traffic it is within the realms of possibility for someone to issue an ICMP DoS attack otherwise known as a "Ping flood"
For inspecting ICMP traffic the following is an example of how you would achieve this:
SecSe# config t
SecSe(config)# policy-map global_policy
SecSe(config-pmap)#  class inspection_default
SecSe(config-pmap-c)# inspect icmp

In regards to the second option, a simple access-rule would be sufficient although as I've mentioned this is an ill-advised method:
SecSe# config t
SecSe(config)# access-list OUTSIDE_IN permit icmp any any echo-reply
SecSe(config)# access-group OUTSIDE_IN in interface outside

Thirdly, in regards to your final point, you may have a static route in but it will never work if you don't allow the traffic back in. The problem here is you will need an access rule to allow that traffic into the ASA otherwise it will implicitly drop it as that's how a firewall works.
As I said, for me to help further I will need your configuration but as I've mentioned this is a question which would be better suited on Network Engineering Exchange rather than here.


Is it worth using a client-side XSS-focused library like DOMPurify?

However if you can't trust anything on the user's end, and ultimately need to process on the server anyway,

DOMPurify is not to protect the server against malicious input from the client.

It is to protect the client against maybe not fully sanitized data from the server but also input from other untrusted sources which might not even be visible to the server providing the main HTML. This might be for example when including third party content or when processing the hash of the URL (i.e. http://example.com/page#hash - the hash is not sent to the server).


What public GPG key do I have to publish?

As I understand the scheme, you now have three pairs of keys: A Master public/private, and two Subkey public/private pairs. Please correct me if I misunderstood.

According to https://wiki.debian.org/Subkeys , it seems like you should publish both of your public subkeys in order for others to both

encrypt messages meant only for you, and
verify your signatures.

  Subkeys make this easier: you already have an automatically created encryption subkey and you create another subkey for signing, and you keep those on your main computer. You publish the subkeys on the normal keyservers, and everyone else will use them instead of the master keys for encrypting messages or verifying your message signatures. Likewise, you will use the subkeys for decrypting and signing messages. [emphasis mine]

Furthermore, do not publish either of your master keys: (again, https://wiki.debian.org/Subkeys)

  You will need to use the master keys only in exceptional circumstances, namely when you want to modify your own or someone else's key. More specifically, you need the master private key:

  when you sign someone else's key or revoke an existing signature,
  when you add a new UID or mark an existing UID as primary,
  when you create a new subkey,
  when you revoke an existing UID or subkey,
  when you change the preferences (e.g., with setpref) on a UID,
  when you change the expiration date on your master key or any of its subkey, or
  when you revoke or generate a revocation certificate for the complete key.

  (Because each of these operation is done by adding a new self- or revocation signatures from the private master key.)


Does a certificate with extended validation provide better security than certificate pinning?

It looks like certificates with extended validation provide better protection than certificate pinning, but I'm unsure about this.

EV certificates do not offer better protection than pinning but worse.

With pinning the client expects a specific certificate, or a specific public key or a specific CA, depending on what exactly was pinned. Without pinning instead the client will accept any certificate issued by a locally trusted CA, no matter if EV or not. The client does not  know that the the original site would use a EV certificate and not simpler DV certificate and thus cannot expect an EV certificate. Thus without pinning it is sufficient for an attacker to compromise any of the public CA, no matter if EV was used or not.

One might then ask why not use pinning everywhere instead of relying on some brittle PKI with the trust in CA's? Simply because pinning requires that all clients need to know the certificate or key of the server before connecting to the server in order to verify it. These keys have to be propagated to the clients in a secure and reliable way and need to be updated whenever a certificate or key changes. This simply does not scale well. A PKI instead scales much better since only the trusted root CA need to be propagated and these rarely change.


What is the NIST/FIPS publication process? How long does it usually take for drafts to become final?

If I'm not mistaken, starting last June, all testing was to go through NIST's Automated Cryptographic Validation Protocol (ACVP).
An overview is available here, and more information is published on GitHub.
I think this provides some transparency into the process, though I'm not sure this is the kind of public/transparency you where asking about.
Cheers,


What's the right way to prevent shell bounce back?

On a production web server, you should prevent outbound TCP connections from being created, excepted for trusted addresses. Any stateful firewall should allow you to create rules for this kind of scenario.

If you're using iptables, try something like this:

iptables -A OUTPUT -p tcp --tcp-flags ALL SYN -m state --state NEW -j DROP

My iptables-fu is a bit rusty, so excuse any errors in that command.

This drops all outbound TCP packets that belong to a new TCP connection, with only the SYN flag set. In other words, it completely prevents outbound TCP connections.


The same origin policy allows:

  Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions. Some HTTP requests require preflight.
  Cross-origin embedding is typically allowed. (Examples are listed below.)
  Cross-origin reads are typically disallowed, but read access is often leaked by embedding. For example, you can read the dimensions of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

The important part here is "typically" and "Some HTTP requests require preflight".

This means that you cannot perform eg PUT requests even though they are "write" actions, because they require preflight.

Which is also what the OWASP article says: You can't use CSRF with other HTTP methods than GET and POST.

Incidentally, you can use xmlhttprequest to send out POST requests:

// hosted on evil.com:
<script>
var xhr = new XMLHttpRequest();
xhr.open('POST', 'http://example.com/test.php', true);
xhr.send("test");
</script>

This will show an error in your browser console about a SOP violation. But the violation is not the POST request (which will be issued), but the potential of reading out the response (which is not allowed).

As the SOP doesn't forbid write actions, it doesn't really relate to CSRF (which is all about write actions). It does however interfere with some CSRF attacks (eg PUT requests or requests with custom headers), so the SOP can be used in CSRF-prevention (eg by checking a custom header or only using PUT requests).


Is User Account Login Related to BitLocker Encryption Key

By default, BitLocker encryption uses a security device, the TPM chip, for key storage. So windows stores the key inside the TPM and makes sure that the TPM does not "hand out" the key unless the original windows system on which the key was created is booted.

So how does this protect your data? You're protected because there's still the windows logon password. This logon password is between someone hostile and your data. The password cannot be brute-forced at the logon screen in a reasonable time. if you don't believe that, please try to enter 100 guessed passwords and see if you can do it in less than 15 minutes. Now imagine someone would plan to brute force your machine. Even with a programmable keyboard, this would take years even for a password of length 6.


If origin was spoofed in this context, this would be down to a flaw in the particular browser that had been exploited. There have been such flaws in the past, such as this one on Safari.

So assuming the user is using a fully patched browser and no zero day flaws exist (!) then your method of verifying the origin cannot be spoofed within the browser when receiving postMessage events.

At the end of the day you have to trust the browser is behaving as expected for it to hold up the client-side end of your security. Yes, a malicious user could cause their browser  to spoof the origin, however if they cannot attack other users or your system itself by doing so and could only attack themselves you should be safe. Of course you should not use the origin value to verify things where a malicious user can gain advantage by spoofing it - you should only be using this value to verify that a user session is not being attacked, and not as a means of validating the user's actions. This is the same reason why you should not have client-side validation only for webforms as the user themselves can bypass it.

To summarise, in your scenario you should be able to trust the origin of the postMessage event.


Nmap scanning single port too fast? Shows as filtered?

It does indeed seem like a timing issue. nmap might be timing out on the single scan and reporting the results as filtered. With the other ports or systems included in the scan, the timeout might be different.

To find out what is going on, you will have to run a packet capture. Wireshark is the de facto tool for this. Run nmap -p 25 10.11.1.227 and capture the results, then run nmap -p 25,5900 10.11.1.227 and capture the results. Compare the differences. Chances are that the differences are obvious.

In general, when things like this happen, always go to the packet traces to see what's going on. You will learn a lot.


Is it safe to use a unix pipe to redirect sensitive output data as input to another program?

The | is anonymous.  The pipe will usually not be accessible to anyone who isn't root or the owner of one of the processes.  As soon as you read the standard input and close it, the cat process will exit, and the pipe will no longer exist to even be exploitable by root or the owner of the remaining process.

That said, it's usually less hassle to code your program to start as root but drop privileges before it gets to the point of actually paying attention to anything coming in from external.  This is the mechanism that's used in email and web servers to let them listen to a privileged port, but not be seen as a root-level externally accessible security hole waiting to happen, for example.


Hugoclose.com malware is causing issues in google chrome

It seems Internet is full of very detailed guides on how to remove this specific Hugoclose.com malware manually, but in short it's removed with the very usual methods:

Remove the browser extensions you are not familiar with (or you have installed recently).
Remove all search providers you don't want.
Change the home page if it has been changed.
If the malware came with some other application, remove that application.

I don't want to link any of the guides as they all are there to promote their own malware removal software.


Not possible. The host can read everything, no matter what it is.

Encrypted memory means there must be a decryption key, and that key must reside in clear, in the memory. The memory the host has full access. Not only access to memory, but the instruction execution too. No matter how you hide that, the host will have access.


How can I verifiably demonstrate that steganography or hidden partitions do not exist?

Your question here is basically the question every steganalysts are asking. Reading from wikipedia page:

  The goal of steganalysis is to identify suspected packages, determine whether or not they have a payload encoded into them, and, if possible, recover that payload.

The usual way to go is to have a set of known not-steganographed data to extrapolate statistical data. Then you try to devise the characteristics of what is empty containers and run the statistical analysis on the set of all files. If the file does not match the statistical class, you are likely to have found a media with steganographed data in there.

The statistical elements will be different for each media types and there is no definite answer as "this file contains hidden data", it's always a probability unless you have the tool to decode it.

Your next question, normalising, is just a new rule. If you code all images in JPEG, the steganographer just need to find a algorithm that is resistant to JPEG (re)compression.


Intensive 586 (ms-shuttle) port scan/exploit/hacking attempts

What you are seeing is mostly botnet traffic where infected routers or other devices are scanning all of the internet in an attempt to infect new devices or re-infect ones that have been cleaned up or hijacked by another crew. Sometimes this is done by exploiting specific vulnerabilities such as the /cgi-bin/ViewLog.asp one you posted, and others spread by brute forcing default credentials. This is totally normal and is just part of the internet white noise. It is also the reason why patching your software and automatic updates are important.
You can use a firewall to block incoming traffic to these ports if you're not using them, but if nothing is listening on the ports then it doesn't really have any impact unless its an exploit for the TCP/IP stack f.ex. that you are vulnerable to.


Yes, moving card holder data (CHD) handling off of your network to PCI compliant 3rd parties is an excellent way of reducing the PCI scope of your implementation. Having the payment page hosted with a PCI compliant 3rd party, and integrating the transmission of CHD to a PCI compliant 3rd party tokenization and secure storage service provider, greatly reduces your PCI scope.

Note that you are still transmitting CHD from this site. So while this implementation would reduce your scope, the integration code would still be in scope. You still need to protect against Cross Site Scripting (XSS), redirection hacks from the payment page to the 3rd party site, etc. I would recommend doing quarterly PCI scans with an approved scanning provider here.

However, I don't feel using a CDN to achieve is ideal.  While a CDN could work, it seems like the right technology for this kind of implementation. The origin server could be considered in scope, making its own PCI compliance an issue, and complicating the implementation.

Given that the requirement is to only work with PCI compliant 3rd parties for the payment pages, I would suggest using a PCI compliant service provider for hosting, like GoDaddy Quick Cart, for example.  With this service, you can get Level 1 PCI compliance for $9.99 per month, and can customize the payment page to handle the CHD, and interface with the tokenization provider.  I think you will have more flexibility with this type of hosted service, and still reduce your PCI scope.


Are there risks associated with using a free SSH server?

OpenSSH is one of the implementations of SSH (like Dropbear for example).

SSH is a protocol to securely connect to servers.

Now, I just searched for "free ssh servers" and the results you are seeing are rather VPN services.

If you want to mess with SSH, just get a Linux distro and play with it (really nothing to do though)


Restrict CA to issue certficates for one domain or to be able to sign just one server certificate

For this to work you need to use a CA and make it trusted. If you control and secure the CA key pair, you can be more confident that others won't sign certs with your CA.
Your idea of creating the CA then deleting (I would suggest shredding instead) would fit your purpose. If others need to trust the CA you created for the product to work on their devices, you can distribute the fingerprint in person for them to validate it.


Owasp Zap's active scan harming the database

Run the active scans against a non-production environment (replica of production). Have a process/script to easily restore a fresh copy of the live database if you break your non-production database during the active scanning.

It is best practice to avoid unnecessary risk on the production site. Also, you can be much more aggressive with your penetration testing against a non-production environment.

You mentioned that your database is "huge". If it is way too large to feasibly copy to non-production in a reasonable amount of time, you could look into decreasing the size of the production database when you copy it into your non-production environment.  This might include trimming the tables that have an excessive number of records that are not required for non-production testing purposes.


How can one read the time in GPG's Literal Data Packet?

This number is Unix time, which is number of seconds elapsed since 00:00 on January 1st, 1970, the Unix epoch. On a system with the standard date utility, you can convert the Unix time into a date:

$ date -d @1562530941
Sun Jul  7 20:22:21 UTC 2019

You can check the current Unix time similarly:

$ date +%s
1562547880


Website using Windows integrated - can user get locked out

Yes, if the user authenticates against a domain controller, then bad password attempts will lock out the account in accordance with the security policy that applies to the account. (The domain controller doesn't care where the authentication attempt comes from.)


What are the most frequent ways someone's password "leaks"?

Phishing, dictionary and social engineering based approaches are far more frequent than database leaks.

Database leaks result in far more passwords being released than via the above approaches because a large scale leak can result in hundreds of millions of passwords being released.

However - why are you asking? For example if concerned about your own credentials assuming secure practices are used by the service a user can protect themselves from database leaks and dictionary attacks by using a secure unique password. I.e. your username, hash pair can leak without the underlying password being revealed. Sophisticated phishing and social engineering can be harder to protect against at the individual level.


Does DNS CAA policy applies to all sub domains?

Does above CAA record applies for all sub domains of google.com?

All subdomains that do not specify CAA records of their own.

See, for example, the example in section 3:

The following example is a DNS zone file (see [RFC1035]) that informs
CAs that certificates are not to be issued except by the holder of
the domain name 'ca.example.net' or an authorized agent thereof.
This policy applies to all subordinate domains under example.com.

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"

And the lookup algorithm in section 4.

If, for example, mail.google.com had its own CAA record (it currently doesn't), that record would apply to requests for certificates for mail.google.com.

  Can any other CA (apart from "symantec.com") that supports CAA would issue certificate for mail.google.com ?

If their DNS queries are successful and they strictly follow the CAA policy, no. As it currently stands, few CAs implement CAA, and some consider CAA more what you'd call guidelines than actual rules, and flag certificates for extra scrutiny, but don't out and out reject issuance.

Regarding your specific example of mail.google.com, any halfway competent CA has google.com on its VIP list and flags requests for certificates, rejecting them outright or making doubly damn sure they're valid. It's very unlikely a random CA would misissue -- or issue at all -- a google.com certificate unless their validation systems were compromised or people had guns to their heads.


Quite obviously, if they can display your password, then they are storing your password somehow. They might cache your password on the client-side when you log in (for unjustifiable reasons, like session management), but more likely their password database is in clear text. Either way, it's stored and it should not be.

And it looks like they are running a upper() function on the password, which wipes out 26 characters from the potential character set that would have otherwise added some entropy.

This is very, very poor security on their part that has had no place for 2 decades.


How to safely save passwords for a future administrator?

Offline password manager
I would use an offline password manager (for example, KeepassXC as an open source option) for the whole list of credentials that may need to be accessed by someone else.
The encrypted file containing the passwords can be given to any relevant persons and management beforehand, or it may be stored in some network location that's accessible also to some of your colleagues. But the passphrase (and possibly 2FA token) to access that file can be physically put in an envelope in a safe to be given to the appropriate person if/when needed.
This also means that you can continuously keep that credential list up to date without touching that 'envelope in a safe'.


Is there an equivalent of meterpreter's "run persistence" for Linux?

Any persistence modules for Linux would be found under than "Local" exploits here: https://github.com/rapid7/metasploit-framework/tree/master/modules/exploits/linux/local

Or in the Linux Post Modules: https://github.com/rapid7/metasploit-framework/tree/master/modules/post/linux

Or in the Multi Post Modules: https://github.com/rapid7/metasploit-framework/tree/master/modules/post/multi

I didn't see any that perform persistence, but like @d33tah said, usually persistence in Linux is simply editing the crontab to run something or installing SSH keys so that you can get back in. Or you can go the route of Kernel rootkits: http://www.securityfocus.com/tools/category/65


Storing email adress encrypted but deterministically

Email addresses are subject to enumeration. There are not so many email addresses. Any deterministic scheme which uses no secret (i.e. no key that a possible attacker knows of) will do nothing against that. I don't know what you suppose that the "double asymmetric encryption" with two public keys achieves; but I know that it does not fix that core problem. Public keys are public.

Symmetric encryption, with a key that the attacker does not have, can be deterministic and yet safe (if done properly) but this hardly applies to your situation, since while you don't need decryption, you do need to encrypt a lot, because the user's email address is what the user types in.

An additional problem with email addresses is that they are not always reproducible: users may employ different casings (case is not significant in the domain part, after the '@', but it may be significant in the local part), use variants (many people have 'login@domain.com' and 'firstname.lastname@domain.com' as valid addresses) and include "comments" (as in 'bob+emailForSpammers@domain.com') with a site-specific notion of what constitutes a "comment". As @Stephen suggests, it is better to simply allocate an ID to each user and use that ID as primary key.


How to retrieve the MAC address of a remote IP

MAC addresses are used for physical addressing. Unless you are on the same physical network as the target machine, via something like a switch, hub, or wifi, you are out of luck.


Linux - user can be in forbidden directory if su to it from user with access - is this concerning?

I wouldn't use the word “concerning”, but it is something you should be aware of. When you run a program with different privileges, you always need to be careful about the environment in which the differently-privileged program runs.

If the program runs with elevated privileges, it needs to be careful what environment it runs in — environment variables are a well-known risk (PATH, LD_PRELOAD, EDITOR, … to name a few among many).

If the program runs with reduced privileges, the environment needs to be careful what credentials the program receives. Credentials include users and group, but also opened file descriptors and similar things. The current directory counts as a similar thing. On this note, sudo closes all file descriptors except the standard ones (0, 1, 2), whereas (at least on Linux) su doesn't touch them.

Passing reduced-privileged processes such as a current directory or file descriptors can be useful. In your case, this allows a program to be executed as user2 and process files in that one specific directory, without allowing the program to access all the other directories that user1 can access but not user2. A classic example with file descriptors is to start a server process as root with a privileged TCP port open, and then drop privileges before executing the server application — that way the application can serve this specific privileged port but no other.

By the way, there's another way this situation (a process cannot change into its current directory) can arise: if the directory's permissions change after the process changed into that directory, that won't affect the process's current directory.

Whether this poses a security risk depends on the specific scenario. Before changing privileges, the current directory is one of the things that may need to be sanitized, like the environment, the file descriptors, etc.


Airodump-ng doesn't capture handshake or sees any devices connected on Kali, but captures everything on Backtrack. How to fix it?

Maybe no one is connected to the wifi spot right now.
(If you do see someone you can "deauth" him in order to get a handshake).
Try on your wifi and check if you do see anyone who is connected while you know someone really is.
Also maybe you're to faraway from the hotspot/this hotspot is on a crowded channel (there are many wifi's on the same channel nearby).


You could have the user authenticate himself by signing the user ID or a session ID with his PRIVATE key. That  value could be authenticated by anyone, using his PUBLIC key. A simple digital signature scheme.


When changing a password, does it have to be completely different?

Why do you change a password?

because you were told to do so;
to defend against someone who knows your current password.

The issue with a small change is that given the current password, finding the new one is much easier.


SSH Version Scan Unsuccessful for Windows XP SP2

TL; DR

Windows does not come with SSH by default so unless you (or someone else) installed it, you won't get results.

If you have installed an SSH daemon on the box (for some reason), try to identify the version with nmap instead. The banner grabbing in nmap is likely more accurate anyway.

nmap -sV -p 22 <<host-ip>>

Assuming the SSH daemon is listening on 22. Adjust the port number if needed.

  Is it possible that it is not able to scan due to patch file which
  maybe pre-installed for these scanners (as SMB was working)?

There is no way to patch against a port scan. And blocking access to the port would prohibit normal operation so that's not an option either. If there is no firewall between the Kali host and the XP box, then Application or OS level IP whitelisting would be the defense.

  If it is pre-installed patch is there any way to remove it or any link
  where I can purchase default Windows XP SP2 (where these scanners
  work)?

Again, this probably isn't the issue. It's most likely because there is no SSH daemon installed on the host.


Why would a banking app require access to browsing history and information about apps running on the device?

When they ask, it can look a little bit intrusive, but it's usually* for security reasons:

Some banks will perform some checks for root access/jail-break (iOs) devices, one of those needs the permission. (Some banks will let you continue using the app and some others no if the check fails, there's no consensus by now because the check is not deterministic, see https://stackoverflow.com/a/3578773/2325522
The information about the apps/processes/history is really handy to detect/trace an infection/account compromise if it's related to a "bad android app". It's gold for the blue team of the bank. (i.e. They just cross the list of apps to check if something "weird" is installed/running/recently visited on the compromised account phone).

*I can't say if they do/don't do something more with the gathered information.


Can I put the session token in the body to protect against CSRF?

Basics of CSRF protection

Most CSRF protection mechanisms work on a basic principle that the HTML form being submitted and the server should have shared secret between them. When the form is submitted to the server, this shared secret is used to identify if the request originated from a legitimate page. There is no way for malicious sites to access this shared secret if it is present in the request body. (Obviously cookies cant be used to store this secret as browsers transmit them to the target domain irrespective of the origin of the page.)

Double submitted cookie

The prevention method that you have described is called double submitted cookie. In this the shared secret is sent using both the cookie and form parameter. The server only has to compare the two values to filter out forged requests.

Why does it not work?

It does work. The session token is indeed a shared secret between the browser and the server. However the session token's primary job is to track the user's authenticated session. A session token present in the cookie is protected by cookie flags such as HTTPonly. This prevents JavaScript from accessing the session cookie, which in turn prevents session ID theft in case of an XSS vulnerability.

Having the session token in the request body of every HTML form increases the attack surface as the session token can be extracted by exploiting a script injection vulnerability. Hence it is good practice to have a dedicated CSRF token do the job.


Are browsers still vulnerable to IDN homograph attacks?

No, Humans are vulnerable to the homograph attack, browsers are unaffected.

Chrome has a partial work-around that offers a false sense of security to those who buy the hype.

In the general case of the attack both domain names are IDN and the user can't be expected to differentiate between two different random-looking strings of ASCII characters.


How to determine the size of payloads available in MetaSploit

The msfvenom -s or generate command is useful for individual payload sizes. Sometimes you will want to know all the payloads within a certain payload size constraint. For example if you are developing an exploit, you know you have limited space to carry a payload of say 100 bytes and you want to know all the payloads that are less than or equal to 100 bytes, you can use payload_length.rb tool provided inside the tools/modules/ directory.
root@kali:/opt/metasploit-framework/tools/modules# ./payload_lengths.rb
The above command will show you size of every payload. If you want to restrict it within a certain size limit, you can always use the handy awk Linux utility:
root@kali:/opt/metasploit-framework/tools/modules# ./payload_length.rb | awk ' $2<=100'
This command is going to tell you every payload in the Metasploit framework having a size less than or equal to 100 bytes.

PS: The question has been answered but it is always good to know more than one way to do a certain task!


Why do password requirements exist while limiting the upper character count?

Cargo Cult
It is no secret that a lot of people who are tasked to design security for systems know very little about information security and are ill equipped for the task. As a source for that claim, I will take years of personal experience as pentester, and the absolute bewilderment for the things I have seen people develop over the years. Not because the developers are bad developers - on the contrary - but because information security has different requirements than normal software development. It's like asking a painter to paint a blueprint of a house.
As such, developers who lack the understanding of what is required of a system that handles authentication and authorization often fall back to the most primitive form of learning: Imitation. We see other people do things, and without understanding why these things are done, we imitate them. "After all, it's done that way for a reason." This process has a name: Cargo Cult Programming.
Originally, cargo cults were cults of tribespeople, who saw modern soldiers receive air cargo with supplies. They thought that this air cargo was a gift from a divine entity, and that the activities of the soldiers were a ritual to summon said entity to bring gifts. As a result, after the soldiers had left, the tribespeople began to immitate their activities to the best of their understanding, making makeshift uniforms and marching up and down, in hopes that this would summon some divine favour.
Cargo Cult Programming is a similar process, in which some developer does something in a particular way, due to some circumstance. The other programmers then blindly implement their solution in the same way, without understanding why the solution was implemented in said way, and what problem it aimed to solve.
About Password Lengths
For example, "DES crypt" would only allow for a maximum of 8 bytes for password length due to export restrictions - which was primarily a legal problem. So any system that used DES crypt would require a maximum character length of 8. Someone who saw this implemented may not know the reason why 8 was chosen for this, and may blindly copy this implementation, possibly not even using DES crypt in the background. So they are not limited by a maximum password length of 8, yet still arbitrarily impose it, simply because they have seen someone else do the same thing.
Misinformation
As for why companies require short, complex passwords rather than long, easy-to-remember phrases? That one is unfortunately on us. For a very long time, security experts tried to get people to make "better" passwords. And in a sense, it's true: <3BZg2Ck is a better password than ILoveNYC.
However, security experts are not infallible and we too learn painful lessons, such as AviD's Rule of Usability:

Security at the expense of usability comes at the expense of security.

Short, highly complex passwords are really difficult to remember for people, and people started to use "systems to make good passwords", like tGbHuJm! (I'll leave it up to the reader to figure out why this is a bad password). Experts changed their advice, instead advocating for long passphrases, like It's monday again and the coffee still tastes like wet socks, but "common wisdom" is difficult to change. When people hear that passphrases should be complex, they see the half-truth how a complex password is better than a simple one, and urge their users to make passwords as complex as possible.
Recommendation
In a system that requires passwords, users should be urged to use a password manager to create a safe, new password. A sufficiently long, randomly generated password will always beat any long, easy-to-remember passphrase, and it's more easily usable too if the browser automatically fills it in for the user.
If that is not a possibility, users should be urged to make long passphrases. Phrases are generally easier to remember for people, and length is king when it comes to strength. However, users can stick to phrases that are publicly known and not secure at all, such as In the beginning God created the heaven and the earth. - any automated check will tell you that this is an amazing password, but my wordlist on my cracking machine will beg to differ. As such, you can try to generate a memorable sentence for the user, or just believe that they know what they are doing.
Finally, after a user has entered a passphrase, it is recommended to check that passphrase with a database like Have I Been Pwned? to ensure that password isn't already known to be insecure.


No, not directly.

As you've observed, SGX ensures the freshness and integrity of transient state in memory, but doesn't provide any mechanism (like a monotonic counter) for ensuring freshness of persistent state. So if you just want to rely on SGX on the local CPU, you can't protect against state rollback attacks. The general solution to this problem is communication with another trusted party which can provide you the basic mechanism to ensure freshness. That could be a trusted machine/service on the other side of a network, or it might be some other trusted hardware like a TPM. In either case, because you'll be communicating over an untrusted channel, you need to secure it (i.e., crypto). If your workload is update-heavy, you'll also run into the messy tradeoff between holding up writes while you wait for communication with the trusted party vs. allowing some window for rollback attacks.


Is there any meaning in only allowing port 80 and 443 today?

Blocking all ports except 80 and 443 can be part of a good defense in depth strategy. If it is your only strategy then you are correct, it will be a flawed one.

A potential exampled layered approach may be

Block all ports at the external firewall minus 80/443
Have an inline IPS (or as part of your firewall) do packet analysis
Sanitize web-app input with a web application firewall
Sanitize db input with a db firewall
Log everything and feed it into a log management system (with alerts)
Backups on everything (whatever your availability strategy may be)
Harden every OS according to whatever baseline/benchmarks you choose (e.g. Org SOP, CIS/DISA STIGS etc)

This is just one very simple example. A good defense in depth strategy has many layers that together build a secure system.


Apparently, the software permits developers to provide their own session IDs, which (because people are often bad at security) might be short and/or predictable. The signature is thus added to create a minimum amount of entropy in the token to prevent guessing or brute-forcing another user's token if the token itself is low-entropy.

Or, as you put it, the odds [against] guessing somebody else's session ID should be astronomical... but you probably generate session IDs using something like "16 bytes from a CSPRNG" and some people instead use Random.nextInt() or even just an incrementing counter or something. In those situations, guessing or even brute-forcing other IDs is pretty easy, so the token is signed as, essentially, a way to "mix in" the entropy of the secret with the (possibly low) entropy of the token without revealing the secret itself.

Obviously, if both the token and the secret itself are guessable and the attacker realizes this, this will still be insecure. But, at some level, there's nothing you can do about a dev who is obstinate about being insecure. No matter how many footguns you take away, somebody will nail themselves to the floor with a pencil.


Who do I inform when a website is compromised

You're doing right. If the admin@xx or webmaster@xxx didn't respond, you may check their website and see if there's any official social media, e.g. Twitter and Facebook. To be ethical, use direct message or private message. Sometimes they're more active in social media.


Is it possible to tell if two ssh users are the same, based on the keys they use?

Yes. Public and private keys are linked in such a way that a certain public key belongs to a certain private key. So if you see two identical public keys you would know that they match to one private key, which likely belongs to one individual.


Secure design for handling mail attachments

Scanning is really the best and only option.  You have to grant access to the message in some way shape or form.  For any situation you can propose to access the information, a sufficiently advanced attacker could bypass it.  You could try viewing the message in a virtual machine, but the attacker could include a virus capable of bypassing the hypervisor.  I suppose you could be guaranteed security if you downloaded each message to a fresh computer, disconnected from the Internet, read the message and then nuked the computer from orbit before reading the next message, but this is likely a tad bit excessive.  Short of that, scanning for issues prior to opening it is the best option, possibly using a VM environment to do so as a second level of protection if you really feel it necessary.

The most practical advise is never open anything from an unknown or unexpected sender... ever.


What LDAP schema is recommended for PKI?

I'm assuming you're trying to deploy your own LDAP backed certificate service. The best matching schema for this purpose is the cosine schema available in all OpenLDAP installations. If you don't want to install the openldap server just to get the schema, then simply extract it from the source code here - http://www.openldap.org/software/download/ . The cosine schema can be found in folder servers\slapd\schema under the root directory of the source code.

Since I don't know the full details of your requirement, I'm guessing that at the minimum set of attribute types that you would need to store for a PKI would be: public certificates of the user, CA certificates and certificate revocation lists. These attributes are available in this schema.

In case you need specific tweaks and customization, you can always add your own supporting schema with additional attributes or objects with custom mix 'n match of attributes. See this reference for more details - http://www.openldap.org/doc/admin24/schema.html . I've had to do this on several occasions, and its difficult to get the syntax right initially, but its straightforward once you get the hang of it.


How does firefox know when to display a green bar?

As stated by James F in an excellent answer at Server Fault:

  The way that EV SSL certificates work is to stick an authority-specific OID in the certificate policies extension field of the cert (which is a standard X.509 certificate otherwise).

  ...the reference OIDs for each authority are shipped as part of the browser's root store of certificates. The user interfaces don't let you add a new CA and say "this is an EV capable CA and the UID is a.b.c.d.e.f".

  I suppose it might be possible to build an open-source browser from source, adding your own CA's cert along with its EV oid to the root store, but you haven't really achieved much by doing so. The browser would no longer be compliant with the CA/Browser forum EV guidelines (which limit the EV-capable authorities).

  Wikipedia has more info on EV certificates here: https://en.wikipedia.org/wiki/Extended_Validation_Certificate

Sure, this looks like a conspiracy by CAs (and browser devs). Yet, this arrangement makes for a less chaotic world.

NOTE: You can issue an EV cert with a green bar in Firefox, but you have to get a debugging build according to http://sidstamm.com/evssl-trust/firefox-evca.html

Getting others to trust your browser may be a bit difficult, though.


How to pentest an AngularJS based SPA (Single Page Application)

Used to teach app pentest classes for a Fortune 20 appsec vendor to Fortune 100 clients. Years ago the state-of-the art for these types of assessments was the OWASP Ajax Crawling Tool where one had to manually input all of the Ajax parameters and actions.

For AngularJS, there is the AngularJS Batarang Chrome Extension in the Chrome Extension Store -- very useful for debugging. If you also happen to run into Node.js (likely), then you can also leverage the iron-node debugging tool. If you do any Javascript prototyping or development, I also suggest checking out the ternjs (Intellisense-like) add-on to the Atom Editor. nVisium Security wrote up a blog post on some of the security issues in AngularJS. Dinis Cruz also writes on AngularJS regularly.

Single-Page Applications can be worked much more efficiently using BurpKit, and to get an efficient crawl, check out htcap.


From Network security: Allow LocalSystem NULL session fallback:-

This policy affects session security during the authentication process between computers running Windows Server 2008 R2 and Windows 7 and those computers running earlier versions of the Windows operating system. For computers running Windows Server 2008 R2 and Windows 7, services running as Local System require a service principal name (SPN) to generate the session key. However, if Network security: Allow Local System to use computer identity for NTLM is set to disabled, services running as Local System will fall back to using NULL session authentication when they transmit data to servers running versions of Windows earlier than Windows Vista or Windows Server 2008. NULL session does not establish a unique session key for each authentication; and thus, it cannot provide integrity or confidentiality protection. The setting Network security: Allow LocalSystem NULL session fallback determines whether services that request the use of session security are allowed to perform signature or encryption functions with a well-known key for application compatibility.
Enabled:
When a service running as Local System connects with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. This increases application compatibility, but it degrades the level of security.
Disabled:
When a service running as Local System connects with a NULL session, session security will be unavailable. Calls seeking encryption or signing will fail. This setting is more secure, but at the risk of degrading application incompatibility. Calls that are using the computer identity instead of a NULL session will still have full use of session security.

This seems to answer all your questions, but please post a comment if not and maybe myself or others could clarify.


1.What is the difference between authentication and authorization?

Authentication is the process, by which a server checks if a user is indeed the user that it claims to be. This is usually done, when the user gives the username and a password, while the server checks these credentials (username, password) with those stored in its database, when the first user created its account.
Authorization is when one entity gives permission to another entity to perform an action. In this case, for instance, it's when a site wants to access data of a user, which are stored and owned in a different website.

2.What is OAuth2 meant to do?

Officially, OAuth2 empowers a user to allow a client website C to access his/her data from a resource server website RS after authentication via an authentication server website AS. This seems quite complex, so to simplify, a common example is when a user signs in a website using his/her facebook account. In that case, the client website and the resource server website are the same (C=RS=the visited website) and the authentication server is facebook (AS=facebook). Note that this was created, so that the C,RS do not learn the password of the user, while being able to authenticate him/her.

3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?

The specificity with the implicit flow is the fact that the access token is given to the user-agent to forward to the application. So, it is solely based on the redirect URI. Thus, this flow does not authenticate the identity of the application, since there is no client secret confidentiality (access token exposed to user and applications running in mobile)

4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?

As described before, in implicit flow the access token is forwarded to the application by the user-agent. On the other hand, in authorization code flow, the client web server gets first an authorization code (after the Resource Owner / user gave access), then makes a call to the API passing (clientID,secretID) with the authorization code to get the access token. This is done, so that in case of HTTP connections (no SSL encryption), the access token is not accessible to man-in-the-middle (routers,proxies etc.). So, the first one is suitable for mobile applications, while the latter one is suitable for server-side applications.

5.Does OAuth2 authentication code flow work for authentication?

Yes, the authorization code flow also authenticates the user through the authentication server.

6.Should you use OpenID instead of OAuth2 for authentication?

Yes.

OpenID is used for authentication. An example is when we want users to be able to sign in in multiple websites with a single set of credentials (signle-sign on).

OAuth is used for authorization, as desribed before. Note that OAuth can be slightly adjusted (as in the example before, where C=RS) in order to perform (pseudo-)authentication, via authorization. But, if we only want authentication, we can use OpenID.

7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.

I guess the real reasons behind this design decision can only be given by the corresponding Google engineers, but I could assume that instead of using both OpenID and OAuth, they selected to use a single protocol for both usages, in order to simplify things. However, be aware of the fact that authentication via OAuth is being done by authenticating someone, through the data he/she possesses. A dull example would be that when I am trying to enter my job's building, I am not asked about my credentials, because my employee card is obviously in my neck. This is how authentication is being made via OAuth, quite simplified. So, you can see that this can make several assumptions that do not always hold under every scenario. And this is the reason that it is generally recommended to use OAuth only for authorization and use OpenID, should you also need to implement authentication.

A nice link describing the various flows of OAuth for reference


You can use browser + PIN-code verification (oauth_callback=oob). It will become semi-automatic, but will allow you to avoid creating "custom url scheme"

see this article, for example


Is possible to exploit C#, Java, Python or any language that is running inside VM (i.e. managed runtime)

It is not possible to have a buffer overflow vulnerability in a managed memory environment such as Java, .Net, or Python provide.   Since the runtime, not the developers manage memory allocations and deallocations, this class of vulnerability is non-existent.

That said, there are vulnerabilities in these environments, but the JVM (or equivalent) is relatively immaterial.   For instance, Java has trouble preventing applets from escaping the sandbox and ASP.NET suffered from a padding oracle.

So, any language offers the potential for exploits aplenty.  Managed-memory languages simply eliminate the vulnerabilities specific to manual memory management such as buffer overflows.  Even this, however, is only true within the runtime environment.  Java allows you to run unsafe code outside of the JVM via JNI, and .Net offers the same via P/Invoke or COM-Interop.   Again, in these instances, the runtime isn't significant, as it's being entirely bypassed.


Looking for resources for interpreting my security logs

The only thing that you can do is to dive into the log and for every record see what that means and what the implications are. That is hard work. I know, and you will expand your security knowledge.

The records that you show, show failures. Though annoying, failures, in general, are not a problem. They indicate that your security measures have worked. You may with firewall rules (or iptables, or router ACLs, or...) deny access to specifiche main po subnets if they become really annoying.

You must also look at the successful connections attempts. Are they logical? Did I expect a connection from this type from this subnet/address?

You should create some base-line of what kind of connections you expect. And you should decide on how bad  it is if someone strange gets access to resources, i.e. do a risk analysis, even for a simple home based site.

The log records that you show indicate that you have an ssh server open. Unless you do regular remote administration this is a bad idea. Even when you do remote administration, consider using OpenVPN.

With an open ssh port, you will see a lot of connection attempts. In this case, 103.79.143.42 was not able to do a key exchange, and 163.172.114.203 tried to log in as the user support, but was unable to authenticate himself correctly. In my experience (ssh server on a home connection on the Internet), you should see failed login attempts on ssh at least 10 times per hour, on average. Higher if your website is a bit more high profile.

You must also look at your Apache access logs. There, you will see some standard URLs that every script-kiddie knows roll by, in my experience multiple times per hour (for a home-website). That will be things like:

118.89.38.35 - - [03/Mar/2019:08:09:53 +0000] "GET /s/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:53 +0000] "GET /MyAdmin/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:54 +0000] "GET /phpMyAdmin1/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:54 +0000] "GET /phpMyAdmin123/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:56 +0000] "GET /pwd/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:57 +0000] "GET /phpMyAdmina/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:57 +0000] "GET /phpMydmin/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:57 +0000] "GET /phpMyAdmins/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:58 +0000] "GET /program/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"

404 in this case means that the page is not found.


What information is still exposed when visiting an HTTPS website using DNS over TLS?

What information about the user's browsing is in principle available to each of the following, if they cared to access it?

Since your question is asking about DNS over TLS, I'm not going to get into HTTP over SSL.

DNS typically goes over the wire in the clear and the information that can be seen is:

Source IP (user)
Destination IP (DNS server)
Query (e.g. www.example.com)
Response (e.g. 93.184.216.34)

By using DNS over TLS, only the following information would be visible to outsiders:

Source IP (user)
Destination IP (DNS server)

This definitely helps with privacy.  Also, keep in mind that this helps with MITM attacks, since in order to establish a TLS session, you need to exchange certificates, thus allowing the ability to verify the server's identity.

  The website

They will always have access to all of your information for each and every time you visit their site.  Your history will be in their web server logs and will show your IP address (unless you use a VPN).

  The DNS provider

They will see everything that you query and have a record of it if they keep logs, again, ties to your IP (unless you run a VPN).

  The user's ISP

They won't be able to see the queries you are performing, but they can see the sites you are going to, but not what you are doing on them due to HTTPS.  They may be able to tell the site by the destination IP address of your traffic and/or by the server name in the TLS client handshake.  Again, if you use VPN, no one of it is visible to them.

  An eavesdropper

Same as the user's ISP.

  Which of these parties, if any, could obtain sufficient information to relate the user's browsing to a real-world identity or location?

No single party would be able to make that determination.  It would be more likely to be someone obtaining logs from multiple sources in order to figure that out.

  How does this differ from accessing the same (HTTPS) website over standard (not-over-TLS) DNS?

Honestly, I don't feel that there would be much of a difference, since in HTTPS, sniffers can see your destination IP and also most of the time the server name is specified in the TLS handshake.

Hope that answers your questions!


Is Bluetooth Low Energy Injection possible?

Bluetooth LE isn't a protocol per se.  iBeacon, altBeacon, and Eddystone are examples of Bluetooth LE protocols which do not inherently have a security mechanism.  For example, an attacker knowing that a particular beacon has a given set of IDs (which are broadcast indiscriminately over the air on a known frequency) can use these same IDs to "spoof" the beacon.

Bluetooth also employs MAC addresses which are also well-known to anyone listening on the Bluetooth frequency and can also be spoofed.

Bluetooth device pairing is an unsecured, coupling mechanism to help users manage devices but does not provide a reliable security layer.  Bluetooth standards have been evolving steadily in response to user and hardware needs but are unlikely to be secured in the same way other high-speed wireless protocols are. You can read a good summary about the evolving Bluetooth standard on Wikipedia


This message is straight from Intel's OpenCL, and hashcat just passes it along.

Intel's OpenCL has some known issues - so much so that there is usually a warning from hashcat if Intel's OpenCL is being used, which notes that errors can be overridden with --force. Did you see anything like that? You may be running into this.

If you are using a stock OS OpenCL of some kind, consider using the latest from Intel.

If you are running under Kali and/or in a VM, consider using hashcat directly on the native platform and/or a non-Kali distro.

Do you get any other errors?


This is bad practice for so many reasons.

RC4 has been broken every which way since Sunday.
Your key generation algorithm is home grown and may not be safe. Perhaps someone on crypto.stackexchange.com is willing to analyze it for you. I'd leave it behind and use a published KDF.
There are known attacks against RC4 that involve subsequent derivations of a starting key. I do not know if there is one for this.
The SHA hashing function wasn't designed to be a good PRNG, nor a good key generator, these aren't its purpose. There may be artifacts within the resulting hash that compromise how any cipher uses it as a key, let alone RC4.
Modern block ciphers with CBC mode are faster than your network stream can handle data, so if this is traveling over a wire, you don't need a stream cipher.

This Q&A has an excellent answer for why you should use block ciphers over stream ciphers. Also, I prefer AES+CBC for Privacy (encryption) and HMAC for Integrity protection over algorithms like EAX or GCM which perform both in one step. Not sure if I could defend this position (security, mathematically), nevertheless the one algorithm to address both bothers me.


Is there an explicit standard for protected health info security similar to the one for the Payment Card Industry (PCI)?

HIPAA describes (at a high level) some policies to follow, and the HITECH legislation further defines some of those provisions. You can look at the Wikipedia HIPAA article for more details on those provisions.

These provisions are required in the USA, I'm not sure about other countries. There is not a global standard, like PCI, as healthcare tends to be dealt with differently based on country.


Do PHP frameworks such as Zend, symfony and CakePHP provide default protection against cross site scripting?

Zend Framework offers an Escaper component to escape output and defend from XSS
Symfony provides an automatic output escaping feature
CakePHP before version 2.4 provided a sanitization class

I recommend you the following lectures for further information:

Secure Application Development with Zend framework


hijacking fedora or ubuntu or windows upgrades on the fly

Trying to replace the packages with other files is certainly possible and even quite easy for an attacker who took control of the firewall or proxy. However, these packages are digitally signed with a private key which is owned by the people at the Fedora headquarters, and the attacker will not be able to forge that; his fake packages will be rejected by the Fedora systems which try to use them. This signature uses GnuPG; see this page for details.

Of course, such an attacker will still be able to prevent upgrades by simply blocking the relevant packages. This alone can be a problem, because it allows him to indefinitely extend the lifetime of known vulnerabilities.

Edit: the same applies for just about every other modern OS out there: they all use some sort of signature mechanism on authentic updates. Linux-based OS tend to use the OpenPGP format while Windows relies on derivatives from the X.509 world, e.g. authenticode; but that does not change the concept.


You're looking at the telnet client, not the telnet server. The telnet client is just a tool which you can use to connect to TCP listeners. If you want to know if your server has telnet open, check it by:

Verify on the server if a telnet daemon is listening on port TCP/23 using tools like ps, netstat and lsof (assuming this is a Linux/UNIX machine)
Test it by connecting to the telnet port TCP/23 from another machine using the telnet client or a tool like nmap


How safe are copies of Firefox that are on various Mozilla mirror sites?

Mozilla downloads are always signed. On Windows you right-click the downloaded file and go to the "Digital signatures" tab. There you can see the signature (should be "Mozilla Corporation") and whether it is valid. When you try to execute this file after downloading it from the web you will get a warning anyway and you will see the signature there as well.

I'm not sure about the particular steps to do the same on OS X but I know that .dmg files are signed as well and the OS can validate the signature for you.


Is Google Analytics HIPAA compliant? How can I find out?

If your ePHI is shared with Google, then you need to have a Business Associates Agreement with them. Google will probably not sign a BAA with you, so that is probably not an option. The only option that remains is not to share any ePHI with them.

It is hard to tell, from your question, whether you are sharing ePHI with them or not. I am not entirely sure, but merely having health insurance might be considered ePHI, which means if your "client/company" can ever be mapped to a person, then it might be considered ePHI. I will assume that you have ePHI in your content for the rest of my answer. If you cannot be sure you do not have ePHI in your content, you should assume that you are covered until you can prove otherwise. This basic question "is it HIPAA covered or not" is the real issue here. Shameless plug: this issue covered carefully in O'Reillys Meaningful Use and Beyond which I wrote (look in chapter 12 does HIPAA cover me?). Because you cannot get a BAA with Google, you must not share, or practically speaking, be in danger of sharing, ePHI with them. If I was your lawyer (and I am both IANAL and IANYL) then I would be concerned that you start using a service like Google Analytics in a channel that does not have ePHI today, and do not re-evaluate that use even after that channel gets ePHI. Make good decisions for what you are doing, and for what you will be doing.

But there is probably a workaround. All you have to do is be sure you are not sharing PHI, and apparently, all you want is to collect data regarding information that is not HIPAA covered (I am assuming that the documents that you are talking about are publicly available non-client specific documents).

To accomplish this, create an hidden iframe in each page of the site that might contain PHI. Inside that iframe, load a document that does nothing except launch google analytics. Ensure that you do not follow googles instructions on making iframe google analytics work "properly". This will allow you to gather brower data on all of your users on every page, without tracking the pages they load or the content of those pages. To Google it should look like you are loading the same page, again and again. Then, assuming you have a single "general documents page" that links to the documents, but contains no ePHI, you can also include the analytics code on that page. This should tell you what document links are being clicked.

Essentially, without knowing how your site is constructed, this is one guess about how you could create a "analytics zone" on your site that would ensure you never made a PHI mistake. I may be wrong about how your site is constructed, but given any reasonable architecture, there may be a way to get this "zone" effect without screwing things up totally.


Should a "password reset" link be valid after changing email?

I would argue that yes, you should invalidate them. The email change may be because the email account is compromised. And there is no harm in invalidating them, as the user is clearly logged in and can just request another one if they need to.

That being said, it is much more important to send a verification email to the old mail before you allow a change and if the user lost access, send instead an undo link valid for at least 7 days (ideally more). Otherwise, you risk account theft.

Lastly, if you support 2FA, you should not allow resetting both factors using just email.

PS: Also you should not allow changing mail for a period of time after password reset.


Min-in-the-Middle attacks in SSL are prevented by the client "making sure" that it uses the correct, genuine server public key. This "making sure" element is what certificate validation is about. When the server certificate is self-signed (i.e. not issued by a trusted certification authority), then such validation must be done some other way. A simple method, which works, is when the client already knows the server certificate (it is embedded in its own code): the certificate from the server is validated by a simple bit-to-bit comparison. There are many ways to do such a validation, and many ways to botch it, so I cannot say whether your specific method is correct or not.

Replay attacks are a completely different beast, and are unrelated to the self-signedness of the server certificate. To make the story short, replay attacks in SSL don't work, because both client and server include random values in their initial handshake messages (the ClientHello and the ServerHello -- see the handshake overview in the standard) and these random values are used in all subsequent cryptographic operations, preventing the raw reuse of previously captured network traffic (which is what replay attacks are about). The same data (e.g. the same session token) will be reencrypted anew, with a new session key for each new SSL connection.


Is ClearChat end-to-end encryption and user authentication secure?

I cannot find any source code of the tool on this site nor do I find any results from independent audits or any kind of common criteria or similar certificates. Essentially only their claims are on this site without any proof or independent test.

  Are these claims accurate?

It is impossible to tell. These claims might be true or might be not. It might be that they believe they are true but that independent test would find security problems. It might also that they knowingly tell lies. It is the equivalent of some stranger telling you to blindly trust him. Would you do it?


Throw out < 2048 bit builtin moduli
On the server: Have a look at your sshd_config and throw out the diffie-hellman-group1-sha1 if it appears in the KexAlgorithms section.
And restart SSHD.
Check with Nmap

how can I test if that is good enough?

Get Nmap and run the `ssh2-enum-algos' script against the SSH server.
The diffie-hellman-group1-sha1 must not appear. It only has 1024 bit.
Throw out < 2048 bit custom moduli
On the server: throw out DH-moduli less than 2048 bits.
Here's some code. It' adapted from a ServerFault question:
awk '$5 >= 2048' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

And restart SSHD.
Check With SSH-Weak-DH Tool
Get, compile, and run the SSH weak Diffie-Hellman group identification tool.
The tool uses a patched OpenSSH client that attempts various times to connect to the server using different DH group parameters for the DH key exchange protocol, thereby determining whether the server has weak DH groups enabled. GDSSecurity explains how the tool works on their blog.
Check with WireShark
I don't really know how to check for this.
Some ideas below:
Sniff the Handshake on the client with WireShark.
Filter for ssh. Find the Server: Diffie-Hellman Key Exchange Reply, New Keys line.
Or quicker yet: Filter directly for ssh.message_code == 31.
Look inside the SSH Protocol | SSH Version 2 | Key Exchange | KEX DH host key section. There is human readable ASCII text in there that will tell you what Key Exchange mechanism the server has selected. If it's something that starts with ecdsa- then you're safe from LogJam. Otherwise you'll have to have to count bytes again. And there'll have to be at least 256. (256 x 8 bits == 2048 bits. Which is what we want as a minimum key length.)
Further reading:

Jethro Beekman, 2015-05-20, On OpenSSH and Logjam (Archived here.)
stribika, 2015-01-04, Secure Secure Shell (Archived here.)


To specifically address the scenario, Facebook doesn't need to wait until a user logs in to capture an OAuth token.  Since you're trusting Facebook as your authentication provider, they can generate a valid OAuth token for any user in their system anytime they please.

Given that, there are three potentially correct answers here.

This is not a threat, because it's outside of your threat model, or an negligible risk.  In most cases this is going to be the correct answer.  It's outside of your threat model, because you're assuming that Facebook is correctly authenticating people and if you get an OAuth token from them, it's for the authenticated user they say it's for.  It's a negligible risk because it's unlikely Facebook cares about your application data, and it's unlikely that even if they do, they're willing to abuse a system they've spent a large amount of money to build and operate, and that is popular only because it's trusted.  That would defeat their larger and more valuable goal of getting their fingers in every corner of the web.
It is a threat, and can be mitigated with a second authentication factor.  If this is a serious enough risk to your application for whatever reason, you can mitigate it for existing users of your app by requiring a second authentication factor that Facebook doesn't have control over, so that you're not relying solely on the OAuth token.
If it is a serious threat, don't use Facebook OAuth at all.  If you really don't trust them, then don't use their system.  Simple as that.  If the data in your application is so sensitive that it warrants requiring uses to create a new set of credentials, make them do that.

All of that said, the vast, vast majority of cases are going to fall under scenario 1.  First, when you choose to use Facebook OAuth, you're doing it so that you don't need to worry about authentication, and threats to authentication (for the most part) become external.  Additionally, the thought that Facebook would abuse the system to harm you or your users is more of a fictional plot than a real threat, and the actually likelihood of that occurring is generally negligible, and not worth the cost, effort, and complexity of mitigating.


Checking "return" parameter in login page

The best way is to create a whitelist of possible URLs, if the redirect is not part of the whitelist you can redirect to a default home page. However this isn't too flexible.

You can also regex the whole thing so it ensures the start of the URI is your website e.g. http://example.com/ and that what which comes after your last / only contains numbers, letters, & or ? and disallow any other characters (you might as well work with relative paths).


Can you stop a BeagleBone from being imaged?

If you don't want someone to steal the BeagleBone and bruteforce it, you can encrypt the whole disk and keep the key online.

You could write a custom program to send the password to your server, and have the server send back the key to decrypt the disk. If someone submits the wrong password a couple times, consider the computer stolen and erase the key. This way you can delete the key even before someone tries the wrong password.


Is it possible to distinguish between a SHA256 hash and an ecc256 key?

Your main assumption that key size is directly related to the format of the keys, parameters or output size does not hold.

Normally the attacker would only have access to a public EC key, which is (usually) not 256 bit, but a point on the curve. This point consists of two coordinate values prefixed with an indicator (compressed or uncompressed points).

Usually a key - public or private - would be encoded using some kind of ASN.1 DER structure (PKCS#8/X9.62). So the format of either keys is usually much larger than the key size. This is different from e.g. symmetric ciphers where the keys just consist of random bits.

ECDSA signatures - just like ECDSA public keys - consist of two components with the (approximate) size of the ECC key size. Usually the signature is ASN.1 DER encoded as well. So it would be pretty easy to distinguish it from a AES256 encrypted block.

All that said, EC private keys (parameter S) are normally fully randomized. And as the output of SHA256 should also look perfectly random to an attacker, there would be nothing to distinguish between the two.

However, if the attacker has access to the key or hash, you would expect that they would also have access to some plaintext/ciphertext combination to verify which algorithm was used.


It's fairly easy to route requests based on whether or not they have a particular header set. The tricky bit comes from determining whether it's set correctly.

Most web authentication goes something like this: you request a page. The application sees that you haven't sent along a session cookie, and redirects you to the login page. You login, and get a session cookie. You request the first page again, the server reads your session cookie and validates it, then sends you the page.

The tricky part for you is dealing with validation. You say you don't want any unauthenticated requests to make it to your application, but that means that not only do you need to verify that the client has sent authentication, but that it's valid. Otherwise, it's easy for an attacker to just set an arbitrary value for their authentication header and get access to your application.

Usually I'd say you should implement access controls in the application. It knows context about the various pages it serves up, and having authentication and authorization bundled directly with the app makes it harder for an attacker to bypass the auth layer. However, based on your question, I'm assuming this isn't a feasible solution for you (because it's a third-party app you can't modify, for instance).

Nginx is really good at proxying http requests. It is not particularly good at implementing application logic. I would have nginx proxy all requests to an auth application, and that application then proxies authenticated requests on to the main application. This will be much more straightforward than trying to implement auth-checking in nginx.


Is it bad to only sign some of a domain's emails with DKIM?

DKIM doesn't tell you anything about whether a message is spam or not (although it's a bit more work to set up, there's plenty of spam that is signed with a valid DKIM signature).  DKIM is all about identity - do I know that this message is from the specified sender (and that it hasn't been altered in any meaningful way)?

No good anti-spam service will reject a message solely based on a lack of a DKIM signature.  If there is an invalid signature, then that's something to consider (i.e. maybe this is phishing); however, it's risky to reject in this case (because signatures can get broken in transit), and most anti-spam filters will not do that (at least by default).

The use of DKIM (without anything else) is to allow the mail client to indicate to the user that the message sender is verified (much as browsers indicate to the user that traffic is sent over SSL, or that a certificate is trusted).

So, the simple answer is yes, it is useful to sign messages, even if you cannot sign them all.  You can't tell your users that they should only trust messages that are signed, but they can at least trust some of them.  (Unfortunately, not a lot of mail clients yet expose this information, and users aren't yet trained to look for it, so the benefits aren't large - yet).

The simple answer to the second question is no, any decent spam filter will ignore the lack of a DKIM signature.

Further to this, there are two ways you can extend your use of DKIM, that do have an impact when only some messages are signed.

Author Domain Signing Practices (ADSP) is an optional extension to DKIM where you specify what should happen to unsigned messages.  Specifically, you can select from three choices:

unknown (this the behaviour you get if you don't use ADSP) - the domain signs some or all mail (or none, I suppose, although it would be then odd to have the record set up)
all - the domain signs all mail.  The recipient (or their anti-spam filter) gets to choose what to do with messages that don't have a valid signature; commonly these would be put into some sort of quarantine or flagged in some way so that the user is aware that they are probably fraudulent.
discardable - the domain signs all mail, and is instructing the recipient (or their anti-spam filter) to silently discard any messages that don't have a valid signature.  This is the same as "all", except that the sender, rather than the recipient, makes the decision about what to do with messages without a valid signature.  Anti-spam (or anti-phishing, in this case) filters don't have to obey an ADSP instruction, but they are likely to.

So right now, you should either ensure that you don't have an ADSP record, or that if you do it is set to "unknown".  Once you are able to sign all messages, you could move to "all" or "discardable", depending on what behaviour you would like.

Similar (but newer) to ADSP is Domain-based Message Authentication, Reporting & Conformance (DMARC).  DMARC incorporates policies for both SPF failures and DKIM failures, and incorporates information about providing feedback (to the supposed sender domain) about failures.  You've got basically the same choices as with ADSP, but more flexibility about how to work.  The example the specification provides as to how you'd start using DKIM/SPF is roughly this:

Deploy DKIM and SPF.
Publish a DMARC policy of "none" with a feedback reporting address (this is like ADSP's "unknown", except that you also state that you want feedback about failures, so if they are really from you, you can figure out how to fix the problem).
Tune your DKIM/SPF use until the feedback reports indicate that all your mail is appropriately authenticated.
Increase the DMARC policy strength to "quarantine" for a small percentage (this instructs the receiver to quarantine any messages that don't meet the policy, but only for a randomly selected percentage of mail).
Gradually increase the percentage (to 100%) as you get more confident that all mail is appropriately authenticated.
Set a DMARC policy of "reject" (again with a small percentage to start with, building over time to 100%), so that rather than quarantining, messages that don't meet the policy are simply rejected.

DMARC is new, so only a few anti-spam filters are using it at present, but that will (probably) increase over time, and there's little cost in adopting it now.

If you choose to use DMARC, then right now you could get to step 2, and then continue through the steps as you manage to get all mail signed.


I think the assumption here is wrong.  They don't have physical access to the machine.  They have supervised access to a very limited control panel for a machine which is built into a bomb-proof safe, bolted to the ground and hooked up to an alarm system with an armed response force.

Get the machine out of the vault and away from supervision and then yes... all bets are off.


Are there any known cases where antivirus software has deliberately ignored malware?

I think the best and most common example of this is software that has malware (specifically spyware/adware) like practices but operates as a "legitimate" business (particularly if they can get this into some terms and conditions and/or rely on users not selecting options correctly or other dark-patterns e.g. "Tick here to confirm you don't want to not install MySearchWebPartner" etc).

For instance there are thousands of posts from irritated people about OpenCandy / ConduitSearch but while some AV engines have now started warning about it, few will actually flag it as malicious.

A lot of the AV companies won't go near them because they are worried about being sued by these companies for loss of revenue if they start blocking them.

I can't find the link right now, but I remember that was the reason Microsoft stated they weren't willing to outright block some software from software silently changing the default search provider or home screen to known nuisance ones for fear of litigation; so they researched providing a warning instead for us to be "better informed".

  Microsoft security products consider adware something that the user should be informed about, and given the choice of whether to remove

http://blogs.technet.com/b/mmpc/archive/2013/06/20/ad-injection-and-you-how-adware-gets-on-your-computer.aspx

See also : http://www.dslreports.com/shownews/58853


Does choice of DBMS matter for protection against XSS and other injection attacks?

protection against XSS attacks ...

XSS is an attack against the client side, not the server side where the DBMS resides. Thus the choice of DBMS does not matter here.

  ... and other similar attacks

I'm not sure what you consider similar attacks. But when talking about DBMS the main attack vector is SQL injection and in case of NoSQL DBMS like MongoDB NoSQL injection.

  Does my choice of DBMS has a role in protection against ... attacks, or is it prevented only through only secure frontend and backend programming?

To protect against SQL/NoSQL injection you better make sure that you choose a DBMS where you don't need to construct query strings from user input but can use techniques like parameter binding - see bobby-tables.com for more details on this.

Apart from that you really should thoroughly verify all user input, and doubly so if your DBMS does not support things like parameter binding.


Is it safe to send the user's encrypted password back to them in the browser? Why?

Short answer: This is extremely dangerous and must be avoided.

There are a few things here that should be changed. First, user passwords must always be hashed. As I said in the comments, bcrypt is a common and appropriate hashing mechanism.

Secondly, sending credentials back to a user leaves it open for abuse by an attacker - there is never a good reason to send this information back to the user. When a user exercises the forgot password functionality of an application, they should log back in with the new password. This removes your feature of logging the user in with their own encrypted password automatically.


Should we enable TLS on backend connection after reverse proxy?

Connections to the backend server should be rejected when the originate from an external address, that is from some other machine outside the secure machine/subnet. This is accomplished by configuring the backend server and/or operating system. If this isn't set up properly then yes, it could lead to a major security breach.

Generally secure connections don't require a client certificate though. Usually the certificate proves the authenticity of the server rather than the client (but there are some exceptions). Some other mechanism (e.g. basic authentication, cookie, OAuth) is required to authenticate the client.


A VPN is like an armoured pipe: it protects the data as it transits between its two endpoints. However, it does nothing beyond these endpoint.

As I understand your question, you have a "VPN provider" that allows you to set up a VPN between your own machine, and some server on the VPN side. Your traffic between your machine and the VPN server will be protected against eavesdropping and alterations -- but only for that portion of the path. Once the data has reached the VPN server, it no longer benefits from the VPN. In particular, if you use plain telnet, then your precious data will travel unprotected between the VPN server and your "webhotel" (whatever you mean by that term).

While most low-scale, amateurish eavesdropping occurs near the end-users (WiFi is a boon for wannabe spies), this does not mean that other network parts are inherently safe.

Therefore, don't use telnet. If you want to do a safe telnet, you must use a VPN that goes from your home machine to the ultimate destination server (the webhotel).