How to only send hashed passwords while not storing passwords in plaintext on the sever?

To summarise the comments:

I don't fully understand the stackoverflow answer you are referring to. In your explanation you send a nonce from the server to the client over HTTPS which is considered broken in this attack. Therefor the attacker obtains the nonce. A cnonce is generated and both nonces and the password are hashed.

The cnonce and the hash are sent over the (presumably insecure) HTTPS connection. The attacker now has the nonce, cnonce and hash. He can try to reverse the hash to obtain the password (bruteforce). But that is not even necessary as the server is willing to accept the hash and grant access. The attack simply resends the hash. As @Matthew stated, you've just created a password substitute.

You could invalidate the server nonce after one authentication so that if the hash is resent it is rejected. This seems like a security improvement since the attacker could only succeed by reversing the hash which is very hard with complex and long passwords.

Does the effort outweigh the benefit? I think so, HTTPS is considered secure if configured correctly. The entire internet is depending on HTTPS to secure authentication so unless your application is very sensitive, you should rely on it.

Good luck on the assignment!


It may look good on paper, but it's a terrible idea.
You assume that the only way to get in your PC is from the first hop, the router closer to you, and that to hack one device, the previous one should have been hacked too. That assumption is incorrect.
Extending your network a little further, there are several enterprise-grade routers, managed by a team of experienced system administrators, and if your assumption were correct, to hack your PC those routers should have been hacked too, right? But we know that is not how it works.
Now, back to the real world. One attacker does not need to hack every single device between their computer and yours, only one (or even none) is enough. If the attacker wants to employ a MitM attack against you, now he have 6 routers to attack and need to achieve only one. As they are chained, MitM in one means most traffic is under his control. SSL will protect you here, but non-SSL protocols (SMTP, IMAP, DNS, FTP) are all vulnerable.
So instead of having only one target, the attacker can have six. And you will have six times more work keeping those routers updated and secure. One 0-day in one router is less probable than one 0-day in any of six routers.
And if seems unlikely to an attacker to target one of the internal routers in the chain, remember that the user can be lead to a page making requests to internal IP subnets (10.0.0.0/8, 192.168.0.0/24, 192.168.0.1/24, and so on) while he watches cat videos. If any router responds, it can be attacked from the user PC.
If the attacker can execute code on the user PC, it can run traceroute and get the address of every router, and use the user PC as a proxy to attack each one directly, from inside. NAT does not protect them at all.
We use to say that any chain is as strong as its weakest link, and you are adding lots of non-necessary links on your chain.


Possible MITM attacks on ECDH-RSA or ECDHE-RSA prevents

No. The private keys are never sent and generating Alice's private key from the public key is viewed as impossible with current technology (assuming the algorithm implementations and parameter selections are secure).

See this answer for a description of Diffie Hellman and how the shared secrets can be constructed without sharing all parameters required to build the shared key.


Web of Trust does not allow you not to be "involved in the CA / RA process". It is quite the opposite: with a Web of Trust, everybody is involved in the CA / RA process. That's the point of WoT: any single user can act as a CA+RA, by verifying the physical identity of other users (the RA part) and then signing their public key (the CA part).

An often overlooked aspect of Webs of Trust is the need for redundancy. To understand it, consider the certificate validation process. User A (let's call him Akhenaton) has a copy of a public key which is purported to be owned by user B (Burna-Buriash). But he wants to make sure of it before using that key for encrypting some diplomatic letters. Fortunately, Burna-Buriash's key was certified by Suppiluliumas: the latter signed (with his own private key) a document containing both Burna-Buriash's key and name. Akhenaton does not know Suppiluliumas' key either, but this key was in turn certified by Tushratta, and Tushratta is Akhenaton's friend and Akhenaton knows Tushratta's key. This allows Akhenaton to verify the signature on Suppiluliumas' certificate, and thus Akhenaton gains some trust in Suppiluliumas' key. He can then proceed to verify the certificate issued by Suppiluliumas to Burna-Buriash, and thus gain some confidence in the key which was alleged to be owned by Burna-Buriash.

Now we see that in the certificate validation process, Akhenaton had to trust both Tushratta and Suppiluliumas to do their job correctly. Indeed, while Akhenaton has first-hand knowledge of Tushratta's key, he must still somehow believe that Tushratta will not try to deceive him by issuing a fake certificate, one containing Suppiluliumas' name, but a key which is, in fact, controlled by Tushratta himself. Tushratta's signature protects the process from interference from third parties (like that never-do-well scheming Aziru), but they do not provide protection against treason by the participants themselves, or even gullibility: Tushratta might have drunk a bit too much of imported Mycenian wine that day, and might have been himself deceived by Aziru, wearing a fake Hittite beard and claiming to be Suppiluliumas.

Things are worse at the next step, because while Tushratta is a personal friend of Akhenaton, Suppiluliumas is unknown to him. Akhenaton has no way to assess the trustworthiness of Suppiluliumas; even if Akhenaton supposes that Tushratta is friendly and sober and that the key which is purported to be Suppiluliumas' is indeed owned by Suppiluliumas, this says to him nothing about whether Suppiluliumas will truthfully do the same RA job with Burna-Buriash.

To state things simply: trust degrades sharply when transferred.

Hierarchical PKI (like what X.509 was designed to support) and Web of Trust PKI (the normal model for OpenPGP) deal with this issue in distinct ways:

In a hierarchical PKI, the structure is pyramidal, with few CA compared to the user base; say, one hundred CA for one million users. Each CA is bound to the upper CA (which certified it) by contractual and legal requirements, so that any mistake or fraud will imply heavy retaliation on the faulty CA. CA are thus "guaranteed" to stay in line and be trustworthy by threatening them with all the Might of the Law. This can work as long as there are not too many CA, and the whole structure is properly centralized.
In a Web of Trust, every user is a potential CA. A WoT relies on the following assumption: there may be some black sheep in the lot, but the majority of users are honest and will not try to cheat, and (possibly) most of them will be cautious enough not to sign each other key after the third pint of Guinness. There is a bit of wishful thinking in that assumption, but let's believe it for a moment. In WoT, you cannot gain enough confidence in a key by verifying a single certificate path; instead, you must verify many paths going through distinct intermediates. This ensures safety to some extent because while some paths may go through cheaters, not all users are corrupt. That's the redundancy I was talking about.

Since redundancy is important for WoT, then user software involved in WoT-based validation MUST support it. The software must build several paths, check that they do not intersect, and verify them all. That's where S/MIME fails at doing WoT: although nothing prevents X.509 certificates from implementing a WoT model, X.509 was not designed for that, and, correspondingly, software which does S/MIME (i.e. email applications like Outlook or Thunderbird) just assume that they are in a hierarchical PKI model and declare themselves to be happy with a single verified path.

That's the important lesson here: the PKI model you choose must be implemented by the verifiers, i.e. the users' applications. If you want a Web of Trust, users must use applications which actively support it, and, currently, this means OpenPGP format (with, e.g., GnuPG).

In the end, Akhenaton trusted everybody. This did not turn well for the Egyptian empire.


If I seed a CSPRNG with a truly random number and call the output, does this make the number more, less or equally "random"?

Since without user-seeding, the JavaScript isaac implementation uses Math.random() as a seed, you would be better off using your own seed. You cannot derive security from an insecure input. If you replaced that call with a CSPRNG input like crypto.getRandomValues(), you would have a better output. But why not just use the built-in CSPRNG if you are using it anyway to seed a less-reviewed algo? Don't roll your own crypto.


Checklist on building an Offline Root & Intermediate Certificate Authority (CA)

Note: This is a (very very long) compendium of various recommendations and actions that Microsoft, NIST, and other well respected PKI and cryptography experts have said.  If you see something that requires even the slightest revision, do let me know.

Before I get into configuring the CA and its subs, it's good to know that even though MSFT's CryptoAPI requires a self-signed root, some non-MSFT software may follow RFC 3280 and allow any CA to be the trusted root for validation purposes.  One reason may be that the non-MSFT software prefers a lower key length.
Here are some configuration notes & guidance on setting up a CA ROOT and the Subs:
Storing the CA's Private Key

Best: Store the key on a HSM that supports key counting.  Every time the CA's private key is used, the counter will be increased.  This improves your audit profile.  Look for FIPS140 Level 3 or 4

Good: Store the Private key on a smart card. Though I'm unaware of any Smart Card that offers key counting, enabling key counting may give you unexpected results in the event log

Acceptable: Store the private key in Windows DPAPI.  Ensure that these keys and the Key Enrollment agent don't end up in Roaming Credentials.  See also: How to enumerate DPAPI and Roaming Credentials

Key Length

Don't use 1024 as a key length... NIST phased it out in 2011, MSFT won't ever add it into your Trusted Root CA store since it won't meet the minimum accepted technical criteria.

Root CAs that supports legacy apps should never be larger than 2048 bits.  Reason: MSFT Support sees many cases where Java apps or network devices only support key sizes of 2048 bytes.  Save the higher bit lengths to CAs that are constrained for a specific purpose (Windows vs Network devices) etc.

The NIST recommends 2048 or 3072 bits.  ECC is supported, though it may cause issues with device interoperability.

Plan for the strongest possible encryption (key length) throughout the PKI, otherwise expect mixed security benefits.

Mobile clients have issues (High CPU) or incompatibility with large keys

Expiration
The algorithm & Key length can have a bearing on how long you want certificates to be valid, because they effectively determine how long it might take an attacker crack, ie the stronger the cryptography, the longer you might be prepared to have certificates valid for
One approach is to establish what is the longest validity you'll require for end entity certificates, double it for the issuing ca's, and then double it again for root ca (in two tier). With this approach you would routinely renew each ca certificate when half of it's lifetime was reached - this is because a ca can't issue certificates with an expiry date after that of the ca certificate itself.
Suitable values can only really be determined by your organisation & security policy, but typically a root ca would have a certificate lifetime of 10 or 20 years.
If you're concerned about compatibility, set the expiration date below 2038.  This is due to systems that encode a data as seconds since January 1st 1970 over a signed 32 bit integer. Read more about this issue here.
Choosing a Hash

You may want to imitate the Federal PKI Management Authority and set up two PKI roots.  One modern SHA-256 for all devices that support it, and one legacy SHA-1.  Then use cross certificates to map between the two deployments.

Review this SHA-2 compatibility list for Microsoft software

Notably:

Windows 2003 and XP clients may need a patch for SHA2 Algorithms which include SHA256, SHA384, and SHA512. See more technical information

Authenticode and S/MIME with SHA2 hashing is not supported on XP or 2003

"Regarding SHA-224 support, SHA-224 offers less security than SHA-256 but takes the same amount of resources. Also SHA-224 is not generally used by protocols and applications. The NSA's Suite B standards also do not include it." source

"Do not use SHA2 suite anywhere in the CA hierarchy if you plan to have XP either trust the certificate, validate the certificate, use the certificate in chain validation, or receive a certificate from the CA. Even though XP SP3 allows validation of certiifcates that use SHA2 in the CA hierarchy, and KB 968730 allows limited enrollment of certificates that are signed by a CA using SHA2, any use of discrete signatures blocks out XP entirely." (source)

Choosing a Cryptographic Provider

View this list of providers for more information

Enable random serial number generation
As of 2012, this is required if you use MD5 as a hash.  It's still a good idea if SHA1 or greater is used.  Also see this Windows 2008R2 "how to" for more information.
Create a Certificate Practice Statement
A certificate practice statement is a statement of the practices that IT uses to manage the certificates that it issues. It describes how the certificate policy of the organization is interpreted in the context of the system architecture of the organization and its operating procedures. The IT department is responsible for preparing and maintaining the certificate practice statement. (source)
NOTE: In some situations, such as when digital signatures are used on binding contracts, the certificate practice statement can also be considered a legal statement about the level of security that is provided and the safeguards that are being used to establish and maintain the security level.
For assistance writing a CPS statement, here is a Microsoft produced "Job Aid"
Best Practice: Although it is possible to put freeform text into this field (see notice below), the ideal solution is to use a URL.  This allows the policy to be updated without reissuing the certificates, it also prevents unneeded bloating of the certificate store.
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.microsoft.com/policy/isspolicy.asp"

Certificate Policies
Also known as issuance policies, or assurance policies (in MSFT), this is a self defined OID that describes the amount of trust one should put into your certificate (high, med, low, etc).  See this StackExchange answer for how to properly use this field.
Ensure Application Policies and EKU Policies match
Application Policies is an optional Microsoft convention.  If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers.
Enable CRL checking
Normally, a Windows Server 2003 CA will always check revocation on all certificates in the PKI hierarchy (except the root CA certificate) before issuing an end-entity certificate. To disable this feature, use the following command on the CA, and then restart the CA service:
 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

CRL Distribution Point
Special Guidance for Root CAs

This is optional in a Root CA, and if done incorrectly it may expose your private key.

All CRL publication is done manually from an offline RootCA to all other sub-CA's. An alternative is to use an audio cable to facilitate one-way communication from the Root to Sub CA's

It is perfectly acceptable to have the Root CA issue different CRL locations for each issued certificate to subordinate CAs.

Having a CRL at the root is a best practice if two PKIs trust each other and policy mapping is done.  This permits the certificate to be revoked.

Getting the CRL "right" is pretty important since it's up to each application to do the CRL check.  For example, smart card logon on domain controllers always enforce the revocation check and will reject a logon event if the revocation check cannot be performed or fails.

Note If any certificate in the chain cannot be validated or is found to be revoked, the entire chain takes on the status of that one certificate.

A self-signed root CA should not list any CDPs.  Most windows applications don't enable the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag and therefore ignore the CDP (this is the default validation mode).  If the flag is enabled, and the CDP is blank for the self signed root cert, no error is returned.

Don't use HTTPS and LDAPS.  These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

Consider using HTTP instead of LDAP- Although AD DS enables publication of CRLs to all domain controllers in the forest, implement HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

Another reason to not use LDAP is because the revocation window to be smaller.  When using AD LDAP to replicate CA information, the revocation window couldn't be less than the time for all sites in AD to get the CA update.  Oftentimes this replication could take up to 8 hours... that is 8 hours until a smartcard user's access is revoked.  'Todo: the new recommended CRL refresh time is: ?????`

Make all the URLs highly available (aka don't include LDAP for external hosts).  Windows will slow down the validation process for up to 20 seconds and retry the failed connection repeatedly at least as frequently as every 30 min.   I suspect that Pre-fetching will cause this to occur even if the user isn't actively using the site.

Monitor the size of your CRL.  If the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

Note: CRL distribution over HTTP with ETAG Support may cause issues with IE6 when using Windows 2003 / IIS6, where the TCP connection is continually reset.

(Optional) Enable Freshest CRL:  This non-critical extension lists the issuers and locations from which to retrieve the delta CRLs. If the “Freshest CRL” attribute is neither present in the CRL nor in the certificate, then the base CRL will be treated as a regular CRL, not as part of a base CRL/delta CRL pair.

The Microsoft CA does not put the “Freshest CRL” extension into issued certificates. However, it is possible to add the “Freshest CRL” extension to an issued certificate. You would have to write code to add it to the request, write a custom policy module, or use certutil –setextension on a pending request. For more information about advanced certificate enrollment, see the “Advanced Certificate Enrollment and Management” documentation on the Microsoft Web site

Warning If delta CRLs are enabled at a CA, both the base CRL and delta
CRL must be inspected to determine the certificate’s revocation
status. If one of the two, or both, are unavailable, the chaining
engine will report that revocation status cannot be determined, and an
application may reject the certificate.

CRL Sizing and maintenance (CRL Partitioning)
The CRL will grow 29 bytes for every certificate that is revoked. Accordingly, revoked certificates will be removed from the CRL when the certificate reaches its original expiration date.
Since renewing a CA cert causes a new/blank  CRL to be generated, Issuing CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly.  More info
Also consider partitioning the CRL more frequently if the expiration is more than 1 or two years, as the likelihood of revocation increases.
The drawback to this is increased startup times, as each cert is validated by the server.
CRL Security Precautions
If using a CRL, don't sign the CRL with MD5.  It's also a good idea to add randomization to the CRL signing key.
Authority Information Access
This field allows the Certificate validation subsystem to download additional certificates as needed if they are not resident on the local computer.

A self-signed root CA should not list any AIA locations (see reason here)

A maximum of five URLs are allowed in the AIA extension for every certificate in the certificate chain. In addition, a maximum of 10 URLs for the entire certificate chain is also supported. This limitation on the number of URLs was added to mitigate the potential use of “Authority Info Access” references in denial of service attacks.

Don't use HTTPS and LDAPS.  These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

Enable OCSP Validation
The OCSP responder is conventionally located at: http://<fqdn of the ocsp responder>/ocsp.  This url needs to enabled in the AIA.  See these instructions for Windows.
Do know that full OCSP validation is off by default (though it should be "on" for EV certs according to the specification).  In addition, enabling OCSP checking does add latency to the initial connection
More secure systems will want to enable OCSP monitoring on the client or the server side
OCSP Cache duration
All OCSP actions occur over the HTTP protocol and therefore are subject to typical HTTP proxy cache rules.
Specifically the Max-age header defines the maximum time that a proxy server or client will cache a CRL or OCSP response before using a conditional GET to determine whether the object has changed.  Use this information to configure the web server to set the appropriate headers.  Look elsewhere on this page for AD-IIS specific commands for this.
Define a policy in issued certificates
The parent CA defines whether or not to allow CA certificate policies from sub CAs.  It is possible to define this setting when a issuer or application policy needs to be included in a sub CA.
Example polices include an EKU for SmartCards, Authentication, or SSL/Server authentication.

Beware of certificates without the Certificate Policies extension as it can complicate the Policy Tree.  See RFC 5280 for more information

Know that policy mappings can replace other policies in the path

There is a special policy called anypolicy that alters processing

There are extensions that alter anypolicy

If you use certificate policies, be sure to mark them as critical otherwise the computed valid_policy_tree becomes empty, turning the policy into a glorified comment.

Monitor the DN length enforcement
The original CCITT spec for the OU field says it should be limited to 64 characters. Normally, the CA enforces x.500 name length standards on the subject extension of certificates for all requests. It is possible that deep OU paths may exceed normal length restrictions.
Cross Certificate Distribution Points
This feature assists where environments need to have two PKIs installed, one for legacy hardware/software that doesn't support modern cryptography, and another PKI for more modern purposes.
Restrict the EKU
In contrast with RFC 5280 that states “in general, [sic] the EKU extension will appear only in end entity certificates." it's a good idea to put constraints on the CA Key usage.
A typical stand-alone CA certificate will contain permissions to create Digital Signatures, Certificate Signing, and CRL signing as key values.  This is part of the issue with the FLAME security issue.
The MSFT smart card implementation requires either of the following EKUs and possibly a hotfix

Microsoft smart card EKU
Public Key Cryptography for the Initial Authentication (PKINIT) client Authentication EKU, as defined in the PKINIT RFC 4556

It also has interesting constraints around validating EKU (link tbd).
If you're interested in having any EKU restrictions you should see this answer regarding OIDs and this regarding contrained certificates
Use caution with Basic Constraints "Path"
The Basic Constraint should describe if the certificate is an "end entity" or not. Adding a path constraint to a intermediate CA may not work as expected since it's an uncommon configuration and clients may not honor it.
Qualified Subordination for Intermediate CAs

To limit the types of certificates a subCA can offer see this link, and this one

If qualified subordination is done, revoking a cross signed root may be difficult since the roots don't update the CRLs frequently.

Authority Key Identifier / Subject Key Identifier
Note If a certificate’s AKI extension contains a KeyID, CryptoAPI requires the issuer certificate to contain a matching SKI. This differs from RFC 3280 where SKI and AKI matching is optional.  (todo: Why would someone choose to implement this?)

Give the Root and CA a meaningful name
People will interact with your certificate when importing it, reviewing imported certificates, and troubleshooting.  MSFT's recommended practice and requirement is that the root has a meaningful name that identifies your organisation and not something abstract and common like CA1.
This next part applies to names of Intermediate/subCA's that will be constrained for a particular purpose: Authentication vs Signing vs Encryption
Surprisingly, End users and technicians who don't understand PKI's nuances will interact with the server names you choose more often than you think if you use S/MIME or digital signatures (etc).
I personally think it's a good idea to rename the issuing certificates to something more user friendly such as "Company Signer 1" where I can tell at a glance

Who is the signature going to come from (Texas A&M or their rival)
What is it used for? Encryption vs Signing

It's important to tell the difference between a message that was encrypted between two parties, and one that was signed.  One example where this is important is if I can get the recipient to echo a statement I send to them.  User A could tell user B "A, I owe you $100".  If B responded with an echo of that message with the wrong key, then they effectively digitally notarized (vs just encrypting) a fictitious $100 debt.

Here is a sample user dialog for S/MIME.  Expect similar UIs for Brower based certificates.  Notice how the Issuer name isn't user friendly.

Alternate Encodings
Note: Speaking of names, if any link in the chain uses an alternate encoding, then clients may not be able to verify the issuer field to the subject.  Windows does not normalize these strings during a comparison so make sure the names of the CA are identical from a binary perspective (as opposed to the RFC recommendation).

High Security/Suite B Deployments

Here is information regarding the Suite B algorithms supported in Windows 2008 and R2
ALGORITHM                                          SECRET           TOP SECRET
Encryption:
Advanced Standard (AES)                            128 bits         256 bits
Digital Signature:
Elliptic Curve Digital Signature Algorithm (ECDSA) 256 bit curve.   384 bit curve
Key Exchange:
Elliptic Curve Diffie-Hellman (ECDH)               256 bit curve.   384 bit curve
Hashing:
Secure Hash Algorithm (SHA)                        SHA-256           SHA-384

For Suite B compliance, the ECDSA_P384#Microsoft Software Key Service Provider as well as the 384 key size and SHA384 as the hash algorithm may also be selected if the level of classification desired is Top Secret.  The settings that correspond with the required level of classification should be used. ECDSA_P521 is also available as an option.  While the use of a 521 bit ECC curve may exceed the cryptographic requirements of Suite B, due to the non-standard key size, 521 is not part of the official Suite B specification.

PKCS#1 v2.1

XP clients and many non-windows systems do not support this new signature format.  This should be disabled if older clients need to be supported. More Info

I would only recommend using it once you move to ECC algorithms for asymmetric encryption. (source)

Protect Microsoft CA DCOM ports
The Windows Server 2003 CA does not enforce encryption on the ICertRequest or ICertAdmin DCOM interfaces by default. Normally, this setting is not required except in special operational scenarios and should not be enabled. Only Windows Server 2003 machines by default support DCOM encryption on these interfaces. For example, Windows XP clients will not by default enforce encryption on certificate request to a Windows Server 2003 CA. source
CNG private key storage vs CSP storage
If you enroll Certificate Template v3, the private key goes into the CNG private key storage on the client computer. If you enroll Certificate Template v2 or v1, the private key goes into CSP storage.   The certificates will be visible to all applications in both cases, but not their private keys - so most applications will show the certificate as available, but will not be able to sign or decrypt data with the associated private key unless they support CNG storage.
You cannot distinguish between CNG and CSP storages by using the Certificate MMC. If you want to see what storage a particular certificate is using, you must use CERTUTIL -repairstore my * (or CERTUTIL -user -repairstore my *) and take a look at the Provider field. If it is saying "... Key Storage Provider", than it is CNG while all other providers are CSP.
If you create the initial certificate request manually (Create Custom Request in MMC), you can select between "CNG Storage" and "Legacy Key" where legacy means CSP.
The following is my experience-based list of what does not support CNG - you cannot find an authoritative list anywhere, so this arrises from my investigations over time:

EFS
Not supported in Windows 2008/Vista, Supported in Windows 7/2008R2

user encryption certificates

VPN/WiFi Client (EAPTLS, PEAP Client)

Windows 2008/7
Not supported with user or computer certificate authentication

TMG 2010
server certificates on web listeners

Outlook 2003
user email certificates for signatures or encryption

Kerberos
Windows 2008/Vista- DC certificates

System Center Operations Manager 2007 R2

System Center Configuration Manager 2007 R2

SQL Server 2008 R2-

Forefront Identity Manager 2010 Certificate Management

More information on CNG compatibility is listed here (in Czech, though Chrome handles the auto-translation well)
Smart Cards & Issuing CAs
If you plan on giving users a second smart card for authentication, use a second issuer CA for that. Reason: Windows 7 requirements
Use the Windows command CERTUTIL -viewstore -enterprise NTAuth for troubleshooting Smartcard logins.  The local NTAuth store is the result of the last Group Policy download from the Active Directory NTAuth store. It is the store used by smart card logon, so viewing this store can be useful when troubleshooting smart card logon failures.
Decommissioning a PKI Tree
If you deploy two PKI trees, with the intent to decommission the legacy tree at some point (where all old devices have become obsolete or upgraded) it may be a good idea to set the CRL Next Update field to Null.  This will (should?) prevent the continual polling for new CRLS to the clients.  The reasoning is that once the PKI is decommissioned, there will be no more administration, and no more revoked certs.  All remaining certs are simply left to expire.
More information on PKI decommissioning available here


What's wrong with storing a username and password as a cookie?

The main problems are:

The username and the password are sent again on every request, making it easier to steal the actual credentials instead of hijacking the session. A compromised session can easily be revoked by removing the access token, but a compromised login requires locking the account and changing the password. Cookies could be stolen...

in man-in-the-middle (MITM) attacks
in Cross-Site Scripting (XSS) attacks
from a local, unencrypted store.

It's impossible to efficiently expire a session server side: this relies on trust that a client forgets about the cookie when it is set to expire. This makes e.g. using shared computers a lot more riskier than using session tokens.

Unless the password is weakly hashed (or stored in plain text), checking it over and over again on every request is total waste of resources.

Similar authentication schemes exists and are even widely used, as for example HTTP Basic authentication (RFC 7617, 2) works like that. If it's absolutely necessary to use such authentication, these problems must be at least mitigated with proper encryption – likely HTTPS enforced with HTTP Strict Transport Security HSTS (RFC 6797).


Assigning static IP address other than 127.0.0.0/8 to loopback interface

I see a number of answers here about the use of binding IP addresses to loopback interfaces. To be clear, this is not uncommon. It's actually something that is done quite often, for example to create a virtual IP address floating that can move (automatically or manually) from one machine to another with a high availability protocol. The loopback interface is always available on any device, which makes it a good interface to bind the address to.
Also, binding IP addresses to loopback interfaces is often used when a device has multiple network connections, and you don't care about which interface is used to reach the device, you just want to communicate with the specific device regardless of the way it's reached. This is used for example when a machine is using a routing protocol like OSPF and BGP and does dynamic routing.
Now back to your question: is this a good thing security wise? I don't think that in the situation you're describing this offers any real benefit to just adding the IP address to a physical interface and adding proper firewall rules there. In fact, you could argue that the added complexity increases the chances of someone forgetting to apply the rules correctly. Also, if multiple interfaces are available on the device, you need to apply the firewall filters on all interfaces. Personally, I wouldn't use a setup like this if your only goal would be to increase security. Everything you're doing there can be done with a nearly identical firewall filter on the physical interface.


NAT separate firewall or other security tools

I don't think it would make much of a difference. NAT has nothing to do with security and the firewall should be your primary defense.

Having a device provide both firewall and NAT services isn't a security risk by itself. The only potential security risk would be the software and configuration of the device. Since there are so many vendors/products on the market and questions about products is disallowed, this cannot be answered anyways.


To my knowledge, CyanogenMod allows you to modify each app's permissions at any time after install. When an app requests a service that you've blocked in this way, the call will fail and throw a java.lang.SecurityException.

Android Marshmallow will partially bring this feature to stock Android, ie some permissions will be modifiable after install, but stock Android will never fully support this for all permission types because allowing you to block an app's internet access, in-app-purchases, etc interferes with Google's ad revenue.

As a final note, I stopped using the Facebook app when they added the mic permission. Too Creepy. When I was playing with the Android M dev preview a few months ago, I tried removing the Camera permission from a bunch of apps. Most apps popped up an error message like I expected when I tried to access the camera. Facebook, on the other hand, went ahead and opened the camera as if nothing was wrong, so I'm highly skeptical that Facebook doesn't play by the rules.

EDIT: Apparently the Facebook app does this in CyanogenMod too, confirmed by @Thanathan in this question.


Why it bothers if someone can de-anonymize anonymous network (like Tor)?

“So we all know that NSA has the ability to track down Tor, I2P and all those anonymous networks.”

Actually we know nothing of the kind. Tor was originally TOR (The Onion Network) and was  developed by U.S. Naval Research Labs (NRL) specifically to provide a mechanism that was both secure and anonymous against nation state level threats. Since then it has been maintained and enhanced by The Tor Project, Inc, a nonprofit since 2006.

“Which is why bother it? I mean all your communication is encrypted through public key cryptography even through the simplest HTTPS connection, ...”

In the modern digital world, secure encryption is easy but protecting content is not the primary threat mechanism. The main problem and the hard problem is protecting attribution. Knowing that “A” talked to “B” is powerful information, even though it’s commonly disparaged as merely meta-data. Examples are legion and include political activists, whistle blowers, or merely private information such as contacting for information on HIV or abortion or the hot topic of your choice.

“There's so much traffic in and out through FB's servers, how would they be possible to identify that this traffic is between you and server and then track you down to your location by the IP exploit from the connection...”

Traffic volume means nothing, this is exactly what computers do really well! Ask yourself how FB tracks and links all those individual connections? Every connection has a “TO” and “FROM” identifier. Tracking it requires nothing more that speed, it’s the very essence of how everything works.

“Or even simpler, why should you use Tor network there isn't any difference between standard HTTPS anymore?”

There is a huge difference! Without going into a lot of detail, Tor uses multiple relays in multiple countries, changing “TO and “FROM” wrappers at each relay. Unlike a VPN, at no point does an individual Tor node know both endpoints of a connection. The server doesn’t know your IP address, only that of the last (exit) Tor Node.

It’s important to note that Tor provides a secure and anonymous transport mechanism. If you use it to log into a known entity like FB, you are announcing your identity. Tor is not magic, if you provide identifiers (cookies), the anonymity of transport becomes irrelevant.


Is there a pentest standard for a web application to nominate it as "secured"?

I want to know if there is such standard that gives a recognition that my web application is secured

There is no such "standard". There are various vendors offering services to check your site for vulnerabilities and then allow you to put some seal on the site to show that you've passed there checks. But, the quality of the checks they do is often very limited (depending on what you pay) which means that these seals should not really be trusted. Apart from that anybody can put an image of such a seal on their site even if the site was never checked or just invent their own trust seal to make the site look more trustable.

See also Sites certified as secure often more vulnerable to hacking, scientists find.

If you really want to make sure that your site is mostly secure hire a penetration tester with a good reputation, give him enough time, money and information to analyze your site and follow his advice in securing the site. Better yet, get the help of such testers and security consultants already in the design phase of your web application so that your developers are aware of the problems and build the security into the design of the application instead of trying to add security on top of an inherent insecure application later.


What can an attacker do with credentials.json

The short answer is "not much" but read the reference posted by Vipul.

The json you have is the authentication credential that you create when you set up the oAuth consent page for your project.  Your application will use this to identify itself to Google and then your users will authorise that your application can access their data.  Theoretically if your application has been given access by a user then anyone with that json can impersonate your application (as the reference says) but when you set up the Client ID you also set up the redirect URL so that should prevent someone actually completing the oAuth using your credentials..

You should, if you have not done so already, go into your project and then in the project / credentials page you will see a list of all the oAuth2.0 client IDs and you will be able to delete your id.  See doc

  To delete a client ID, go to the Credentials page, check the box next
  to the ID, and then click Delete.

Aside: Posting secrets into Github and then removing them from history is tricky and yes the Google oAuth documentation isn't the easiest beast to follow.


A secure connection with an application and a dedicated server

I know of at least one technology that does what you are wanting: stunnel

stunnel is a secure proxy that uses public key cryptography. A typical use case scenario is securing a http web service. This is done by running the proxy on port 443 to receive and send secure messages, and directing the unencrypted traffic to the http web service, which is running on port 80. Port 443 is then exposed to external networks, while port 80 is restricted access so that only connections from the local machine are allowed.

stunnel can be configured as both a server and a client, which as I understand is the solution you are looking for.

Disclaimer: I haven’t used it before, I recommend  doing your own research before relying upon it.


Visual verification of DH parameter hashes vs derived password hashes

I assume from your question, there is another communication channel between Alice and Bob that can be used to verify the parameters (for example, Alice could call Bob and tell him the hash of g^A).

Theoretically, Eve could intercept g^A and compute its hash. Then Eve could try to perform a preimage attack (which can be virtually impossible, if proper hash algorithm has been chosen, but can be easy, if an improper algorithm has been chosen). Having g^E1 with the same hash as g^A and g^E2 with the same hash as g^B, Eve could facilitate MITM attack.

So it seems to me that verifying the hash of the secret g^(AB) is a better choice.


Use Nmap's service version detection. Using a recent version of Nmap (so that you have the most complete database of probes and response matches), run:

nmap -sV -p 9081 1.2.3.4

And the result should be shown. If the port responds to any of Nmap's probes, you will either get a positive match or the response will be shown in a blob at the end of the scan with a request for you to submit it to Nmap for further identification. You can often get some idea by looking at the blob what kind of service is running, even if Nmap doesn't really know.


While your VPS may have a valid certificate for your domain, your browser is expecting the certificate ot match www.facebook.com.  Without a trusted certificate for that domain, the browser will be unable to connect over HTTPS.

Having a certificate for one domain is not good enough to establish a TLS connection for any other domain.


What are the advantages in using LUKS + hardware encryption on SSD?

Do you trust the hardware encryption on the SSD? If you do then it's fine. If you don't trust it then you're better off with LUKS since not many vendors provide sources for the firmware, so you won't be able to audit it.


If you run ssh in full debug mode you can have it log the content of all packets and then go back and extract the passwords from that. you can do this bu running

ssh -dddddddd

or add it to your /etc/ssh/sshd_config:

LogLevel DEBUG3

this runs it once, in non-daemon mode and logs way more than you care about. you can improve this by disabling the sshd service and running ssh with the -ddddd from xinitd.

At work I currently maintain an open-ssh fork that includes this ability because it uses an external web service to verify the passwords. If you can afford to maintain an open-ssh fork it will likely give a cleaner experience.


What's the State of the Art of Homomorphic Encryption?

There are two types of homomorphic encryption.

Partially homomorphic encryption is about computing one type of operation over encrypted values. For instance, you know E(m1) and E(m2), and, without knowing the private key, you can compute E(m1*m2). Several efficient algorithms which allow for that are known, especially ElGamal (which allows you to multiply encrypted messages) and the Paillier cryptosystem (which allows you to add encrypted messages). Partially homomorphic encryption is useful for some protocols, e.g. electronic voting (the idea is that you can tally together encrypted votes, and decrypt the result at the end). Partially homomorphic encryption works well and has done so for at least a decade.

Fully homomorphic encryption is about computing two types of operations over encrypted values: from E(m1) and E(m2), you can compute E(m1*m2) and E(m1+m2). Fully homomorphic encryption allows for arbitrary computations; ultimately, you could provide encrypted inputs to a biiig computer, which will run the computation and provide the encrypted result, without needing to trust that big computer. The idea is that the state of a transistor in a virtual circuit can be encrypted, and the additions/multiplications are sufficient to emulate state changes based on inputs to the transistor. The big computer would have to run a virtual CPU, with a few homomorphic operations for each transistor in the virtual CPU and for each clock cycle. Needless to say, this looks expensive.

Unfortunately, the best known fully homomorphic encryption algorithms (derived from Gentry's work in 2009) are awfully slow and inefficient, making it not worth the effort (i.e. the whole Amazon S3 cloud could not compute homomorphically faster than what a single smartcard could do without the encryption). The research area is not dead, far from it; but it is very new and has not yet produced anything practical.


What is the difference between SRVHOST and LHOST in metasploit?

SRVHOST is generally the option that you set when you are serving a exploit on a web server and LHOST is the option you would set if you were using a exploit that is not going to be served on a web server.


Should a Web Search with Evernote results be a concern?

This sounds like Evernote simultaneous search, I'd say that it will be sending the search queries you enter to the evernote service in order to provide this feature.

Whether that's a problem for you will depend on whether you're happy with Evernote seeing that information.  Obviously you trust them not to be actively malicious as you've installed their software on your system, so if you're concerned more about their privacy pratices, a good route would be to look at their published privacy policy and see whether you're comforatable with the uses they could make of the data contained in your search terms


Can an unregistered phone with a prepaid SIM card be traced by the police?

This looks like a question that would be asked by a Don! Always assume that the police could end up catching you. It may take them time, and they would need to be properly motivated.

If that someone was just revealing the location where his little sister hides her candies, he probably wouldn't attract much attention. On the other hand, if he was leaking state secrets for a long time, he would probably get caught. There are also a lot of other real-world factors that would affect it, too, like the infrastructure around him (eg. the existence of multiple safe houses) or the ability of fleeing to a country that will cover up your actions :)

It is enlightening to see the history of "El Chapo" Guzmán, a powerful kingping that used what was considered quite sophisticated methods to authorities, by using several intermediate agents relaying back and forth the orders and replies from/to the boss. Yet, the authorities managed to use the phones to locate him anyway.¹ (The usage of BlackBerry instead of WhatsApp is irrelevant for what they did)

Focusing on the actual issue on how he could actually be traced, you should take into account that the network operator does not only obtain information about the SIM card, but also the handheld serial number (IMEI) and other less expected information, such as the model and brand of the smartphone. Law enforcement could thus track the connections performed  from this device with the proper support of all involved mobile networks.

Another information leak source that could be used to track his is that, even though he only uses the WhatsApp app, many more applications will be running and, potentially, connecting to internet servers (including connections performed by the OS itself). So there will likely be other sources for detecting him while the phone is on.

Obviously, this traces would only be able to reveal at most the location where he was while the phone was powered on and connected to the network, but getting a number of historical locations, could reveal enough information. The main obstacle would probably be the time required once he connects to LE knowing about it and being able to reach there, as well and the kingpin speed in leaving that place.

If that time was 0, they will obviously catch him. If they find his old locations with a lag of several days, it is unlikely to be enough by itself, but patterns would emerge: he is moving towards that city, he has been in that zone for several weeks, etc.

Combining this with external intelligence about the gang (eg. who could be hiding him in that zone? how much activity do other members show?) could indeed end up leading to his detention.

¹ See La BlackBerry que delató a 'El Chapo' (Spanish) - Google translate


Why not crack a password a character at a time?

Because most operating systems hash passwords once entered (and store them in a database).  This means that the entire password is converted into a collection of cryptographic hashes, random-looking strings of characters into which the passwords have been mathematically transformed to prevent them from being misused.

So, once a password is hashed for a well defined hash, there is no way to attack each character.  That is circular logic. To attack each character you must know each character.  To know each character you must attack each character.


we have several users on a WiFi. apparently one of them has hacked in and is denying service to others. what can be done?

There are several ways an attacker can deny people's access to Internet.

For example SYN flood or MitM.

MitM is more probable and much more efficient though, popular app WifiKill uses this principle (it makes the device(s) think that it's the router and then it drops all their packets)

I suggest:

start intercepting traffic
once you're sure that an attack has happened already, stop intercepting
open the capture file in Wireshark

Analysis:

Write down your router's MAC address and local address.

Type "arp" into the Wireshark filter box to see the ARP packets

If you see something like 192.168.0.1 is 01:23:45:67:89:ab
where 192.168.0.1 is your router's local address but 01:23:45:67:89:ab is not its MAC address, you are seeing an MitM attack based on ARP spoofing (which is what WifiKill uses)

You can use arp -a (on Linux) to see the local/MAC addresses.
I think you will see one MAC address twice if an attack is running (and of course the router's MAC will not be the value that you have written down)

What's really nice is that ARP packets in Wireshark are very easy to understand even for not-very-technical person.

You will see conversation like:

Who has 10.0.0.6? Tell 10.0.0.138
10.0.0.6 is at 00:17:f2:20:e6:bf

And SYN flood is obviously enormous amount of SYN packets in extremely fast rate.

Defense:

You can block their MAC address at the router, but be aware that they can change it.

  apparently one of them has hacked in and is denying service to others.

Be sure you're using WPA2 without WPS. You can add MAC filtering, but note that it's easy to bypass. However, if the attacker obtained the wifi password from a legitimate machine, they might not be able to avoid being MAC filtered. Always use multiple layers of security.

Summary

The attack is most likely based on ARP spoofing, which can be easily detected if you have a packet capture sample.

To make sure this does not happen again, secure your network as much as possible.


What Partial Homomorphic Encryption implementations exist and how do I leverage them?

El Gamal encryption allows for multiplication. This occurs within the group on which El Gamal runs; hence you are multiplying numbers modulo a given prime, not "plain" integers. If you can multiply you can divide (inversion in a group of size q is done by raising to the power q-2, so this is a matter of performing some multiplications). El Gamal is implemented in libgcrypt (used in GnuPG) but you would have to do the multiplications yourself (El Gamal is used in the OpenPGP format, but not for its homomorphic properties).

Paillier encryption allows for addition. There again, addition occurs in a finite group (here, numbers modulo n, a big composite integer). I am not aware of implementations of this system in widespread generic crypto library (my non-awareness does not imply inexistence, though) but a simple google search finds a few Java-based implementations (Java offers BigInteger, making implementation of such systems easy).

An important point is that such encryption systems are randomized: for a given plaintext, there are many possible ciphertexts. Thus, you cannot know whether two ciphertexts correspond to the same plaintext or not. A fortiori, they do not allow comparisons (order within a finite group is not well-defined anyway). Note that a comparison method would not be compatible with a secure asymmetric encryption: anybody could encrypt chosen values to guess the encrypted data with a dichotomic search. On a general basis, the key words for that are "data mining". Performing data mining on encrypted data is a widely unexplored field, with substring matching as a kind of Holy Grail. Briefly stated, there is nothing immediately applicable there.


when a web application is vulnerable to RFD (Reflected File Download)?

As far as I understand, a webapp is vulnerable to RFD (Reflected File Download) only when the header Content-Disposition: attachment which force the download is set in a response with JSON body,

Not necessarily.

See for example this article which states that IE 8 and 9 will download all JSON as file, and that the download attribute on a link can be used to force a download in other browsers.

I tested this with a current version of Firefox, and at least there, it does not work cross origin (except via right-click -> save as). If you can post HTML links to the original origin, an attack is still possible using Firefox. I can't test on Chrome, but there it should work without that.

  but in any case we want to save a plain JSON file in the user computer ?

An attacker wants to save a file on the users computer with a name - and extension - they control and with content they at least partially control, and they want this file to be delivered from a trusted domain (by the vulnerable application) so that a user will trust and execute it.

  and giving a significant name to this file via Content-Disposition: attachment; filename="whatever.txt" really mitigate the attack ?

Yes. The idea of RFD is that an attacker can determine the filename of the file so that it contains a malicious extension. If you set the filename, that is not possible. I am not aware of any bypass which would allow an attacker to overwrite the given filename.


Validity, Owner Trust, Trust Signatures & Certification Level

There are multiple notions of "trust" in PGP, which I've had to disentagle.  Here is what I found ...
The issue we must deal with when considering using a key for communication, is whether that key is "valid".  Meaning, does the person controlling the secret part of a key, legitimately own the identities listed on the key - ie. name, email address, jabber address, etc.  The keys of people who we know, who we communicate with already and give us their keys directly, are automatically valid.  But what of people we don't have this kind of direct contact with, but with whom we want to communicate?  We find a key purporting to be from them, perhaps on a keyserver or communicated to us by someone who claims to be or know them.  Is it really owned by them ("valid")?
To try to get some handle on this, pgp institutes a system of attestation, called "certification" (colloquially, "signatures").  When I certify a key, using my own, I attest, "Yes, I know this to be a valid key; ie owned by the person whose name is listed and who controls the listed email address."  When I find a key that purports to be from someone with whom I want to communicate, I can look at the certifications.  Maybe among those signatures is a key owned by someone I know.  Or maybe among them there is a key owned by some public personage, who has his own key on his website and is in a position to know the person with whom I want to communicate.  By this means, I can try to work out how likely it is that I have a valid key.
PGP attempts to help with this validation procedure in various ways.  The first is encoded in the certifications themselves, which are carried along with the key I'm trying to validate.  When certifying a key, the "--default-certification-level" can be set to 0 or 1-3.  These indicate various levels of certainty by the signing party, in the validity of the key.  Level 0 means that no claim is made about how certain we are, while 1, 2, 3 are progressively higher levels of certainty: from basic belief, to extensive verification.
PGP's second means of supporting our attempts at validation, is to operationalize a notion of "owner trust."  That is, I have the keys of various friends.  I sign those keys as valid, but when it comes to the signatures my friends place on the keys of people that they know (but I do not), I may put in each friend a different belief in their care regarding validation of those keys.  Perhaps one friend only signs keys of people they know very well.  Perhaps another may meet people at "signing parties," do a perfunctory check of an ID (perhaps checking for that person's control of the key's email address or not), and then agree to sign the key.  Among these various friends I have a private notion of how much I trust their diligence.  I encode this trust level in a private database that is kept with my pgp certificate ("key") using the --edit-key <fpr> trust command to gpg.  I can associate that friend's key with a trust level of "full", "marginal", "untrusted", "unknown".  My own key is given "ultimate" trust.  This is called "owner trust", a codification of how much I trust the diligence of the owner of the key.  Using these values, PGP can then calculate a level of validity (called a "calculated validity" or also, confusingly, a "trust value") for keys that I have not signed, but which may have been signed by others that I know to be valid: eg. my friends or those public personages mentioned before.  The parameters used for this calculation are subject to user control (see --trust-model), but typically, any key signed by a fully trusted key is valid and any key signed by three marginally trusted keys is also valid.  A key with signatures by less than three marginally trusted keys is "marginally valid", and a key with no signatures has "unknown validity."  This is known as the "classical trust model."
Note that this mode of calculating a level of validity / "trust value" interfaces to the first described validation procedure through the option --min-cert-level, defaulting to 2, which discards signatures with certification level below that value (ie. 1 is discarded, but NB: 0 is kept).
The third means of supporting attempts at validation is the system of trust signatures, via --edit-key <fpr> tsign.  As opposed to "owner trust", "Trust Signatures" are public certifications that attest to a certain "depth" of trust by the signing party.  A trust signature of depth 1 is similar to a standard certification in which I am attesting to the validity of the key.  A trust signature of depth 2, on the other hand, announced not only my attestation of validity, but it also makes a proclamation that is equivalent to "full trust" in the "owner trust" model.  That is, I am publicly stating that I give validity to any key signed by this key.  In the trust signature model, a key with signature of depth 2 is called a "Trusted Introducer." I am accepting the validity of keys at one remove.  Offering a trust signature of depth 3 goes beyond the "owner trust" model, publicly declaring that not only do I give full validity to any key signed by this key, but I also fully trust them, giving validity to any key signed by those.  ie. I am accepting the validity of keys at two remove.  This is called in this system a "Meta-Introducer."  Depth can go to any level.
This notion of trust is typically used in organizations for delegation of authority.  As such, it is usually associated with a "domain", within which authority is being extended.  That domain may typically be a website of a company, and validity would only be conferred by trusted meta/introducers to UID's within that domain.  Such signatures can be revocable or non-revocable.  They can also be "local."  That is, very much like the classical trust model, kept private even when keys are shared.  I suppose this is a kind of secret delegation of certifying authority.

Monkeysphere has an excellent reference on OpenPGP Trust Models (on both classic & trust signatures)
But note the error:  Trust level 1 actually just means validity.  Trust level 2 is "full trust" (in an owner trust system where the signature by one fully trusted key confers validity) aka "Introducer".  Trust level 3 means I fully trust anyone that this person fully trusts, aka "Meta-Introducer".
A PGP whitepaper on trust signatures as a more flexible form of certificate authority.
Some discussion about trust signatures from the gnupg e-list:
Questions about trust signatures
The "pgp" trust model: the relationship    between classic ownertrust designation and trust signatures
Multiple trust signatures

Regarding my issue of cross-certification of keys mentioned at the end of my question, I see that within a certificate keys are cross signed using --default-cert-level 3.  That would probably be sufficient, but to get my trust model to work properly, I would either have to make sure to set each key to "ultimate" trust in the owner-trust model, or use the (offline) master certifying key to give a trust signature of depth 2 to the sub-master certifying key.  The latter could give a non-revocable trust signature of the same depth in return.  This would be like setting up the master certifying key as a certificate authority (see that PGP whitepaper).


How to use subkeys for encryption and signing with Enigmail?

It is worth noting that the configuration described in the question above is currently impossible. This is because the Enigmail developer has refused to add custom key selection functionality--see here and here--claiming there is no reason to expose the end user to such "advanced configuration." That's really unfortunate.

Anyhow, I run Debian, so I naturally assumed all Enigmail dependencies would be installed along with Enigmail, but they were not.  The solution to fixing the error was install the pinentry-qt4 package, which has the description:

pinentry-qt4 - "Qt-4-based PIN or pass-phrase entry dialog for GnuPG."

The error message, "Key not found or not valid..." threw me off the trail.

Again, this solution only fixes the error, not the situation I described in the question.


Should I wait until Spectre and Meltdown is fixed in hardware?

I'd personally say, buy the new laptop if you need to replace. I see multiple vendors offering protection at their own respective layers. From OEMs who provide BIOS / UEFI layer. Microsoft / others at OS layer (https://support.microsoft.com/en-in/help/4073757/protect-your-windows-devices-against-spectre-meltdown) and even browsers such as Google Chrome have started offering protection mechanisms. (https://threatpost.com/google-patches-34-browser-bugs-in-chrome-67-adds-spectre-fixes/132370/)

All in all while the vulnerability itself cannot be fully remediated at software / drivers / firmware level (although intel can  theoretically take care  of this at firmware but we'd all have to bear a performance brunt of upto ~30%>. Combination of patches make exploitation difficult unless you're targeted by extremely potent and determined attacker.

True fix lies at hardware level and intel has not given any updates on when it plans to do this. Although I found the following

There's a possibility, however, that it won't be Skylake-X at all, but rather Cascade Lake-X. Cascade Lake is an incremental revision to the Skylake-SP/X platform: it adds some extra AVX512 instructions, it should include hardware fixes for Spectre and Meltdown attacks, and it should support faster memory

https://arstechnica.com/gadgets/2018/06/intel-is-launching-a-28-core-enthusiast-chip-but-probably-not-at-5ghz/

Enjoy the new laptop. :)


Is there a way to tell if an Android app really uses SSO(Single Sign On)?

You cannot know, unless the native browser is shown. That's why Google disallowed any "web view" approach when authenticating against their OAuth2 system:
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

The RFC also recommends native browser in these cases:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12

  OAuth 2.0 authorization requests from native apps should only be made
     through external user-agents, primarily the user's browser.  This
     specification details the security and usability reasons why this is
     the case, and how native apps and authorization servers can implement
     this best practice.


Do I need CSRF protection in this setup with a REST API backed with oauth2 and a basic auth SSO auth server?

To answer your initial question: you do not need to implement CSRF counter-measures on your resource server, if you are not using cookies (sessions) and you are not using basic authentication within the browser.

Cookies and the Basic authorization header are stored by the browser for every domain name you visit, and every time you send a request to a site, the saved cookies and Basic authorization header are automatically added to the request headers.

Since you are using an access token, and presumably sending it using Authorization: Bearer <token>, you should be secure. Your browser does not know how to handle this kind of authorization and that is also why you have to manually add this header in every request.

Redirect URIs

You are using pre-registered redirect URIs, which is recommended by the OAuth 2.0 standard. This ensures that your authorization server only sends authorization codes to sites that you trust.

It is important that your redirect URIs are using a secure scheme, such as HTTPS, otherwise you are vulnerable to a MITM attack.

Exchanging authorization code for access token

Your site is receiving an authorization code through a query parameter, when you are redirected back from the authorization server. Most likely, you are immediately exchanging the authorization code for an access token, which should revoke the authorization code afterwards.

The state parameter should be used here to prevent CSRF attacks, e.g. by sending a random value to the authorize endpoint, and checking that you are receiving the same value with the authorization code. In a SPA, you could save the random value in local storage i.e.

In a SPA, you have to worry less about this, than e.g. in a stateful server-side web application. What happens, if an attacker redirects you to the authorize page, from his own web page? You end up in your own SPA, where the attacker should not be able to continue.

In a stateful server-side application, it's possible that by doing this authorization, you will actually link accounts together, and things can start happening. (Depending on the application, of course.)

CORS on token endpoint

First off, CORS is only checked by your browser, so you must not rely on it to stop an attacker from using your token endpoint.

To circumvent CORS here, all an attacker would have to do, is to create a proxy endpoint, which just sends the request to your token endpoint.

Moreover, the token endpoint only works if it receives a valid authorization code.

CORS on the authorize endpoint

Normally, you would redirect your users to the authorize endpoint, where they would (sign in and) click an authorize button, granting access to the application.

Without CORS, a likely attack is that an attacker can create his own site, where he uses XHR/fetch to retrieve your authorize page. And assuming that the user is signed in (statefully) on your authorize page, he would be able to click the authorize button, without the user's consent.

There is no scenario where it is necessary to use XHR/fetch to retrieve the authorize page. So you can safely block it with CORS.

Authorization server

If your authorization server is stateful, as you write, then you should implement CSRF protection whenever you perform an action that can change something. It's best practice to do this in general, and if you add an update password function in the future, you already have the necessary code to protect against CSRF.

Recommendations

It sounds like you understand the OAuth spec. and it looks like you are doing what you are supposed to.

The obvious recommendations are to use HSTS with preloading (and HPKP), to prevent MITM attacks.
Ensure that your authorization codes are short-lived and can be used only once. They do not need to be valid for very long, in normal scenarios it is used immediately after being granted.
Do not store final access tokens, refresh tokens, authorization codes in your database. Instead store an identifier (e.g. 64 bytes of random), and issue a signed version (e.g. JWT). This prevents attackers from extracting access tokens from your database, since the attacker cannot use it anyway.
Use a standard implementation of OAuth, don't roll your own.


How does actually countersignature work in authenticode?

Finally, I've found the answer, the one lies in RFC3161:

 To verify a digital signature, the following basic technique may be used:

A) Time-stamping information needs to be obtained soon after the
  signature has been produced (e.g., within a few minutes or hours).

  1)    The signature is presented to the Time Stamping Authority
        (TSA).  The TSA then returns a TimeStampToken (TST) upon
        that signature.

  2)    The invoker of the service MUST then verify that the
        TimeStampToken is correct.

B) The validity of the digital signature may then be verified in the
  following way:

  1)    The time-stamp token itself MUST be verified and it MUST be
        verified that it applies to the signature of the signer.

  2)    The date/time indicated by the TSA in the TimeStampToken
        MUST be retrieved.

  3)    The certificate used by the signer MUST be identified and
        retrieved.

  4)    The date/time indicated by the TSA MUST be within the
        validity period of the signer's certificate.

  5)    The revocation information about that certificate, at the
        date/time of the Time-Stamping operation, MUST be retrieved.

  6)    Should the certificate be revoked, then the date/time of
        revocation shall be later than the date/time indicated by
        the TSA.

If all these conditions are successful, then the digital signature shall be declared as valid.


Are there any good tools to test the encryption quality of data?

Existence of a tool that can guarantee security of some encryption system would entail proving a number of hard scientific problems, up to and including the famous P vs NP. Right now, no cryptographer has succeeded in proving that secure encryption or hashing can actually exist, let alone designed a tool that could test a given system. All we have are candidates: not functions that cannot be broken, just functions that we don't know how to break, though we have tried hard.

What can exist is a tool that runs some statistical analyses on, say, the output of a purportedly secure PRNG, and declare whether some bias appears. If a statistical analysis tool finds a bias, then it is obvious that the cryptographic algorithm is pure junk. However, if it does not, then it does not prove anything one way or another. Almost any algorithm, weak or not, produces outputs in which  statistical analyses systems won't see anything obviously fishy.

The practical way to assess the security of an encryption system is:

Is the method documented (precisely, down to the bit level, enough to potentially write an interoperable new implementation) ? If not, then it is probably not secure.
Has that documentation been published as a protocol for inspection by cryptographers for at least two years ? If not, then you cannot know if it is secure.
Has the implementation good repute, do developers publish known security issues and produce fixes promptly ? If not, then don't use that tool.


Can an attacker sniff physical network traffic through WiFi?

TLDR: Basically with what you're asking, only ARP broadcasts, unless you subnet your wireless from your wired network.

Overall it depends. First, your computer on the ethernet may occasionally send out broadcasts to the whole network. For example, if it needs the MAC address of a machine on the local network, it will send out an ARP broadcast to all machines on the local network, including the attacker's. This doesn't tell the attacker much, however, other than that there is another computer on the network, and he might possibly deduce it's connected by ethernet since he can't see any other Wi-Fi traffic.

However, at this point he can do what is called ARP cache poisoning. His computer could respond to the broadcast sent by your computer looking for the machine on the local network, claiming to be the machine it's looking for. Then your computer will continue to send it data directly, because it thinks it's talking to the right host.

Of course, the attacker would be found out pretty quickly if his computer wasn't set up to reply correctly to the traffic you are sending it. It helps for the attacker to anticipate what kind of connection your computer will be trying to make. And if, say, your computer is trying to open an RDP connection to the attacker's computer, that's not very useful for the attacker anyway. The real danger of ARP cache poisoning is if the host your computer was trying to initiate a connection to was its default gateway to the Internet. The attacker could just forward all your traffic to the real default gateway while acting as a middle-man, sniffing all your traffic.

Fortunately, if the scenario you are referring to is a home Wi-fi network, the default gateway your computer was looking for was the Wi-fi router itself, and though I am not an expert on Wi-fi routers I would assume the Wi-fi router would be smart enough to not forward an ARP broadcast requesting its own MAC address. Plus the attacker would have to beat the router at replying to the broadcast, which seems unlikely, but I suppose could be possible if you had like the worst Wi-fi router ever made.

Anyway, once your computer has the correct MAC address for its default Internet gateway or whatever MAC address it was looking for, all communications will be sent to that MAC address directly. If you were connecting to another computer connected to Wi-fi, the attacker can still see that traffic though.

This explanation also assumes your Wi-fi router is otherwise secured from the attacker controlling it directly. If you, say, left the router admin password at default or something then he might be able to change the settings to have the router forward him all your traffic, or overwrite the router's firmware with one he supplies to have the router forward him all your traffic.

Finally, if you're really worried about these ARP broadcasts coming from your computer, however infrequent and mostly useless they are unless they are for the default gateway which they shouldn't be, then on a nicer router you might be able to subnet the local network to have the Wi-fi be one subnet and the ethernet be another. Then the router shouldn't even forward ARP requests across Wi-fi.


Is it acceptable for security engineers to have admin access to production servers?

Good question. This is a difficult topic. The easy answer is, "it depends" and there is no perfect answer. Also, it's not possible to give a prescriptive answer whether they should have this access without considering detailed scope of the teams. But I'll attempt to provide better context.

First, work must get done and the Security Engineers have a good point if they can't accomplish their work. Make sure that the Security Engineers need access. We should break down the problem to identify whether Security Engineers need access or not. These initial steps might be obvious, but I'll list them anyhow:

What tasks do Security Engineers need to accomplish? Be specific. The answer to the question heavily depends on the scope of the Security Engineers' work!
Of these tasks, what gaps exist in their current access?
Is there any means of giving them access to the needed information / controls without providing them direct access?
Is it worth doing so? Often it may be too much work or too expensive (i.e. not worth it) to try and implement a solution for them to have the information and controls needed. And in this case direct access is the best/cheapest solution.

If the Security Engineers require access (most of the time they do), then you need to employ defense in depth to try and be as safe as possible. In other words, the company needs to attempt to take steps to prevent an incident and have a proper response capability. By doing so the risk can be reduced to a manageable level.

Some considerations:

Incident Prevention

Least Privilege: Give the fewest number of Security Engineers access as possible. More accounts with access increase the attack surface. For each account you need to worry about:

the account being compromised, and
the employee causing either intentional or unintentional damage.

Strong Authentication (multifactor): Enforce strong authentication to prevent the account being compromised and help enforce non-repudiation.
Limit accessibility: If possible, reduce the ability to reach the system of the network by requiring access to the intranet, VPN, or from a jump box.

Incident Response - if an incident occurs these will help you deal with the situation

Non-repudiation - Administrator access to systems must be well documented and audited in a means that prevents, as much as possible, an Administrator from denying he/she executed the actions.
Separation of duties - For example, Security Engineers shouldn't have the ability to modify logs. This helps with non-repudiation. Also, make sure a Security Engineer can't do irreparable damage by not giving them access to backups of configurations/software/data.

There are many more, but personally I feel as that if the above are well established then the Infrastructure Team would feel more comfortable with giving the Security Engineers access.

In summary: Give the teams the access they need to do their job. Don't limit their access to necessary resources. Yes, this means you're increasing your attack surface, but you can use defense in depth to minimize risk.


Where is the TOTP secret key stored on client applications?

For the Google Authenticator app on Android, the shared secret is simply stored inside a SQLite database file that can only be read by the Google Authenticator app. If you have a rooted Android device, you should be able to view that file and the secret it contains easily.

As for other apps or other platforms, I am unclear about the implementation but I would be surprised to see if it's stored in any other fashion.


Mitigation of potential risks with the recent Intel ME exploit

AFAIK, stuff such as AMT(AMD has the same stuff call PSP), only works with a particular network adapter that supports the instruction.

So besides disable AMT from the BIOS, which is not 100% disable (unless you flash the firmware), another mitigation method is unplugged network cable connect to Intel adapter, and use another network adapter that doesn't talk Intel AMT.

There is a many Network adapter vendor. , since AMT is proprietary to Intel, so it is a safe bet that to use any external network adapter (not the internal one, as some may license technology from Intel to make it AMT ready) that not using Intel Chipset(with a risk of AMT enable).


Security/Malware implications of storing data in a BLOB as opposed to the file system

This has been answered before on this site, in extensive detail.  See these questions:

What are the security risks of letting the users upload content to my site?
Is it necessary to scan users' file uploads by antivirus?
Antivirus for scanning anonymous file uploads
What steps should be taken to validate user uploaded images within an application?
What are security risks of serving user uploaded files without Content-Disposition?
Why should I restrict the content type of files be uploaded to my site?
Is it safe to store and replay user-provided mime types?
Is it safe to serve any user uploaded file under only white-listed MIME content types?

The answer to your question about databases and the format of the file is: it doesn't matter how you store the file.  The risks are the same whether the uploaded file is stored as a BLOB, as a binary field, on the file system, or in some other way.  That's just an implementation detail.

What's important is what kind of validation you do, and how you address the threats.  Any of the standard mitigations can be made to work, no matter how you decide to store the uploaded file -- the important thing is that you understand the risks and select mitigations appropriate that are appropriate for your application.

For general advice relating to web security, OWASP is always a good resource.


What degree of physical destruction is sufficient to ensure an SSD is not readable?

No. It is not sufficient physical destruction to ensure that any data is unrecoverable by anyone.
According to
https://www.backblaze.com/blog/how-to-securely-recycle-or-dispose-of-your-ssd/, the memory chips themselves must be cut into 1/2 inch (1.27 cm) or smaller pieces.

It’s important to check the specs of any potential shredder to make sure the shred size is small enough to actually destroy the memory chips on your SSD, however. The shred width should be 1/2 inch or less if you want to make sure the chips get properly mashed up.
No, a woodchipper like the one from the movie Fargo does not have a suitable shred width for secure SSD disposal.
If your SSD looks like a hard disk drive, you should be able to take it apart with the right tools (usually the small screwdrivers included with a computer repair kit are all you need). Inside you’ll find the SATA memory chips where data is actually stored; you can remove them and destroy them however you see fit, whether it’s by a shredder or some other destructive means.


Does posting my computer name publicly make my system vulnerable?

Generally, no. Your computer should not be reachable from outside your local network, with the name or without.

However, it can leak info like your real name, or allow people who know your computer name to match your online username to the real you. Whether this is a major concern is up to you.


Is it okay if passphrases to KDFs are "predictable"

The first thing that comes to mind is that once someone knows one password, they know all past and future passwords, too.

The idea behind changing them yearly is to counter that problem if someone ends up cracking the passphrase, but it also provides at least a little protection against past employees who may have had access to those passphrases, too.


What is the difference between SSH and IPsec?

@graham-hill's answer is correct in general but short and pedantically incorrect, so I'll expand upon it.

SSH is at the Application level - you can think of it as SSH/TCP/IP, or SSH-over-TCP-over-IP.  TCP is the Transport layer in this mix, IP is the Internet layer.  Other "Application" protocols include SMTP, Telnet, FTP, HTTP/HTTPS...

IPSec is implemented using two separate Transports - ESP (Encapsulating Security Payload for encryption) and AH (Authentication Header for authentication and integrity).  So, let's say a Telnet connection is being made over IPSec.  You can generally envision it as Telnet/TCP/ESP/AH/IP.

(Just to make things interesting, IPSec has two modes - Transport (outlined above) and Tunnel.  In tunnel mode, the IP layer is encapsulated within IPSec and then transmitted over (usually) another IP layer.  So you'd end up with Telnet/TCP/IP/ESP/AH/IP!)

So - you ask "explain the difference between the two" -

SSH is an Application and IPSec is a Transport.  So SSH carries "one" type of traffic, and IPSec can carry "any" type of TCP or UDP traffic.*  This has implications described below:

You ask, "how they would appear differently to the user" -

Because IPSec is transport layer, it should be invisible to the user - just as the TCP/IP layer is invisible to the user of a web browser.  In fact, if IPSec is being used, then it is invisible to the writer of the web browser and web server - they don't have to worry about setting up or not setting up IPSec; that's the job of the system administrator.  Contrast this to HTTPS, where the server needs a private key and certificate properly enabled, SSL libraries compiled in, and code written; the client browser has SSL libraries compiled in and code written and either has the appropriate CA public key or screams loudly (intruding upon the application) if it isn't there.

When IPSec is set up, because it acts at the transport layer, it can support multiple applications without any trouble.  Once you've configured IPSec between two systems, it's a really minor difference between working for 1 application or 50 applications.  Likewise, IPSec makes an easy wrapper for protocols that use multiple connections like FTP (control and data may be separate connections) or H.323 (not only multiple connections, but multiple Transports (TCP and UDP)!).

From the administrator's point of view, though, IPSec is heavier-weight than SSH or SSL.  It requires more setup as it works its magic at the system level rather than the application level.  Each relationship (host-to-host, host-to-net, or net-to-net) needs to be set up individually.  On the other side, SSH and SSL are generally opportunistic - using either a PKI (CA) or web of trust model, they make it reasonably easy to trust the other end of the connection without much setup ahead of time.  IPSec can be opportunistic, but it isn't generally used that way, in part because configuring an IPSec connection often requires trial and error.  Interoperability between different vendors (Linux, Checkpoint, Cisco, Juniper, Etc) is not seamless; the configuration used to make Cisco<->Checkpoint is likely to be different than the configuration used to make Cisco<->Juniper.  Contrast that with SSH - the OpenSSH server doesn't really care if you're running Putty, OpenSSH (*nix or Cygwin) SSH, or Tectia SSH.

As far as speed goes - I don't have any good numbers to give you, and part of the answer is "it depends" - if IPSec is involved, then the actual IPSec processing is likely to be offloaded to a firewall or VPN concentrator with dedicated fast hardware, making it faster than SSH which is pretty much always crypting using the same general-purpose CPU that's running the server operating system and applications as well.  So it's not really apples-to-apples; I'll bet you could find use cases where either of the two options is faster.

* This isn't strictly true.  SSH supports a terminal application, file copy/ftp application, and TCP tunneling application.  But effectively it's just a really rich application, not a transport - its tunneling is not an IP Transport replacement.


Session id remain same after and before logging in asp.net application

Not a bug, the Session Cookie is created regardless of 'user' authentication. The sessID cookie is ONLY an Identifier (X Client has X Cookie). Once a user has been authenticated with the server you may continue to use that cookie to identify the authenticated user.


Passwords: store encrypted, view in plain text

In general:

A one-way hash is non-reversible (hence the term one-way)
Encryption is reversible (provided you have the decryption key)

For regular authentication, we use store password-hashes in the database. Then we hash a user-entered password and compare that to the hash in the database. This way we can authenticate a user without ever storing the password. If the user chose a 'strong' password, it'll be impossible (or at least immensely difficult) to obtained the users clear-text password even if the entire system was compromised.

However, what you're asking for is to retrieve the cleartext password -- which isn't required under most circumstances. The user already knows their password (otherwise they wouldn't have been able to log on) -- and if the user forgot, we'd generally reset the password, by first authenticating an email address or phone number first, and then re-writing the hash for the new password.

If instead you're asking to store 'data' on the account that isn't accessible to anyone without the password -- then the general solution most password-managers utilize is by encrypting the data with key derived from the user password (because user passwords can be quite weak). The data can be a encrypted blob, that would be decrypted on the user-end using their derived key.

The drawback (sort of) is that if the user loses their password, there is no recovering this data, but for most password managers this is actually a 'feature' because nobody wants this data stored in the clear on any server.

Again, the solution would be quite useless if the user chose 'Password1234' as their master password, but there are other solutions for that.


Many suspicious requests are going from my browser whenever open any site

All the URLs in your first screen capture/snippet are related to ad-providers who show ads on webpages you visit to gain revenue. The plugins and addons shown are legit.

So, its a possibility that something else is causing the traffic, possibly some ad-injecting programs or DNS hijacking. May be that's even not on your machine, but on modem/router/ISP.

Try setting your DNS servers to any of the following (how-tos described in the linked pages itself):

Norton Connect safe : http://connectsafe.norton.com
Open DNS            :
https://www.opendns.com/home-internet-security/

[edit] Sorry, I saw your MBAM screen capture very late. It seems the issue is related to DNS itself. You must inspect your modem/router DNS configuration (log-in to those devices) and change to above entries if necessary. Make sure the firmware of modem/router are up-to date (restart modem/router later).
To verify the settings on your machine, issue the below command at command propmt (CMD.EXE):

ipconfig /all

and check the DNS server entries.

To avoid ads in webpages, use addons like ublock, adblockplus, noscript and ghoestry (for firefox)

  I scan my system with many antiviruses too, but still facing the same issue. And sometimes I click any link will redirect me to a porn site or other sites.

No security software can work 100% perfect all the time. I don't know if malware removal assistance is permitted in the community nor I'm entitled to do so, but if you suspect infection, you can get it removed and fixed freely at volunteer forums like bleepingcomputer or geekstogo.


Free software to demodulate the signal exists, see http://bellard.org/linmodem.html

For the physical signal acquisition on first approximation I'd use a digital oscilloscope, something  like https://www.sparkfun.com/products/11219 but it should be possible to do it a lot cheaper unless you plan to reuse it for other projects.

If you can cut the line two modems should be usable, and the modems could be gotten for cheap, with your computer in the middle.

If you can't even strip the phone cable a http://en.wikipedia.org/wiki/Hall_effect_sensor is the way to go I'd say, in conjunction with the digital oscilloscope.

Interesting project, I would love to read more about it if you succeed.


Why should I choose SHA (such as SHa-512), instead of bcrypt or PBKDF2, for FIPS-compliance?

FIPS 140-2 does not cover the topic of password hashing. Thus, there is no password hashing function which would be "FIPS-approved" in that sense. Using SHA-512 "as is", with or without some salt and regardless of how you inject the said salt in the engine, would not grant you the NIST approval. NIST simply does not approve (or disapprove of) password hashing.

The closest you can get in the NIST world is SP 800-132, that lists approved methods for password-based key derivation, something which is quite close (but not identical) to password hashing. NIST approves PBKDF2, as long as the underlying primitive used in PBKDF2 is itself "approved" (i.e. it is HMAC used with one of the SHA-2 functions).


Using VPN in order to continue working from home?

Can someone please explain what is a VPN ...

A VPN is a virtual private network, essentially a virtual network cable which allows you to be present in some remote network with your laptop without actually being physically present at the remote location.

  ... and is it possible for me to set it up from my home by using my company laptop?

In order to securely use a VPN into your company network the endpoint inside the companies network has to be setup by the IT department and they also need to install the necessary software to access the VPN on your laptop (or provide it to you) and provide you with the login credentials and also instructions on how to use the VPN. Depending on the security policy in your company there might also be additional restrictions on what you are allowed to do with the system when working from home.

Thus, contact your IT department for further instructions and help.


How to exploit XSS in POST request when parameter is going in body?

You can not craft a link that contains a POST body. So you will have to go a somewhat different route.

You will need to create your own page that contains the payload:

<form action="http://target.com" method="post" onload="this.submit()">
  <input type="hidden" value="payload" name="fieldname">
</form>

Or you can achieve the same effect just using the JavaScript fetch API. Then you need to trick the victim into visiting this page.

This will be a little bit harder since the URL will be different and perhaps look a bit fishy. If you want to avoid that, you can go looking for open redirect vulnerabilities and leverage them to take the victim to your page.

Of course, if the payload is stored on the server, and displayed on a page that can be visited later, this is much simpler - just make the victim visit that page. This is what is called stored XSS.


Will a wildcard SSL work properly for an A record subdomain pointing to another domain/website?

First, an A record can only point to an IP address, not a hostname.

Secondly, once the clients hit that IP address - which seems to be your own server - it needs to have a valid certificate for the hostname requested (his.subdomain.com would need *.subdomain.com). Obviously, you need your server to answer for this hostname/vhost.

www.somedomain.com doesn't have anything to do in this picture.

Also, SHA2 is a different topic and has nothing to do with the vhost setup. This relates to the signature of the certificate which you don't own and have no control over.

To correctly understand all those elements, I suggest referring to the OSI model. Being able to abstract complexity of different layers is extremely useful to correctly understand the big picture without mixing concepts from different technology altogether.


Protecting data through an XOR operation with sufficiently long keys

What you are describing is one-time pad.

Assuming that you each bit of the key is used only once, the one-time pad is considered a perfect cipher. Of course, if you reuse any part of the key, the whole scheme becomes laughably weak.

The biggest weakness of the scheme is the difficulty of the key exchange method. The keys used in the one-time pad must be of the same or longer length as the message. If you have a secure method of transferring an arbitrary amount of information for use as key material, why not just use the same transfer method to transfer the actual message?

Also, the key material must be truly random.


is iptable whitelisting secure enough in AWS

Most of the providers are actually pretty good in securing their networks, but IP whitelists are still not a way to "secure communication". Though they can be an additional security measure, you'll still have to roll encryption and authentication to secure the connection.

However, most of the cloud providers allow you to set up private networks. This will give you an IP space that is guaranteed to be "yours" and is not routed to the public internet. If you want "internal" communication between servers you should very much use that, instead of messing around with iptables and public IP addresses.