Can identification imply authentication in biometric systems?

Not sure about whether it can be used as a standalone authentication system but it can be used as a part of multi-factor authentication system.

Reference:

More info:

Identification

Identification is nothing more than claiming you are somebody. You identify yourself when you speak to someone on the phone that you don’t know, and they ask you who they’re speaking to. When you say, “I’m Jason.”, you’ve just identified yourself.

In the information security world, this is analogous to entering a username. It’s not analogous to entering a password. Entering a password is a method for verifying that you are who you identified yourself as, and that’s the next one on our list.

Authentication

Authentication is how one proves that they are who they say they are. When you claim to be Jane Smith by logging into a computer system as “jsmith”, it’s most likely going to ask you for a password. You’ve claimed to be that person by entering the name into the username field (that’s the identification part), but now you have to prove that you are really that person. Most systems use a password for this, which is based on “something you know”, i.e. a secret between you and the system.

Another form of authentication is presenting something you have, such as a driver’s license, an RSA token, or a smart card. You can also authenticate via something you are. This is the foundation for biometrics. When you do this, you first identify yourself and then submit a thumb print, a retina scan, or another form of bio-based authentication.

Once you’ve successfully authenticated, you have now done two things: you’ve claimed to be someone, and you’ve proven that you are that person. The only thing that’s left is for the system to determine what you’re allowed to do.


Should the Payload of Push Notification also be encrypted?

I think you should encrypt this, because of profiling data leak, this information can contain the time of chat between two clients (even they delete messages) and it's very good for branding, you can say you have the fully encrypted application. but to determinate the actual risk you need to ask your self, with that information like "message ids" what you can get about the user, when I say you I mean every person with access to the database and server. can you find out the message from who and for who? if yes its data leak risk.

about the signal app you according to this link they have data leak in the desktop application(but they send text body in notifications its nightmare) but in your case, you don't send text body to the clients.

according to whats app faq: your messages, photos, videos, voice messages, documents, status updates, and calls are secured from falling into the wrong hands.

its seems they don't encrypt notifications. but zulip mobile encrypt notifications


You Will Have to Travel

The short version of the answer is: you will very likely have to travel, the user base is not very large, especially not those forming the largest strongly connected component of the web of trust (ie., the network of people all being able to mutually find a trust path in the web of trust). Less than 100.000 people (as of 2017) form that group, don't expect many of those living by chance near you "in the middle of nowhere".

Subcommunities

When looking for certifications on your OpenPGP key, also consider what community of people you want to be trusted in. Just having "some certificates from trusted people" does not really help you at being trusted by all OpenPGP users, not even those being well connected. If you want to get a trusted identity in a given group, especially try to meet with people from that group. For example, meet Debian fellows for signing keys if Debian is (one of the) groups you want to participate and need a trusted identity in the OpenPGP web of trust therefor.

Keysigning Parties and Meeting People for Keysigning

If you are living in the "middle of nowhere", you will very likely have to get out of there. Attend meetings with key signing parties, expect such especially at free and open source software conferences. Again, if you for example want to get closer to the Debian community, join a Debian meetup. Chances are good you can find people for key signing there.

There is a (rather outdated and rarely used) directory of people willing to meet for key signing: http://www.biglumber.com/ (but experience shows that lots of entries are completely invalid by now, and only few actually respond).

Certificate Authorities

Finally, there are some "certificate authorities" (although OpenPGP does not really know this term): I know of CAcert which also signs OpenPGP keys (but again, you will likely have to travel to meet people to get CAcert-assured), the German Heise Verlag with its "Kryptokampagne" and if you have a German ID card, there is a service by Governikus that uses the electronic functions of the ID card to verify your identity.


Using an in-browser tabula recta to generate passwords

Your system would probably work in theory, but seems significantly flawed in practice.  There are several practical weaknesses in the way it will be used:

You don't describe how you will convert the master password to the seed for the RNG.  This is potentially a weak point.
You haven't specified how users will associate a starting point with a particular site.  Without a way to save this, it will be impossible to use.  Depending on a user's memory will lead to password reuse.
Users will tend to pick the same or a small number of starting points in the tabula recta based on human tendency, significantly reducing your entropy.
A tabula recta involves more manual work than users will actually want to use in practice.
RC4 has biases in the initial keystream.  If this is not corrected for in your RNG, this will insert biases into your tabula recta.
You do not provide a good way for users to rotate passwords other than picking a new starting point for that site.  Combined with #2, this will make it even harder for users to remember the starting point for a given site.


Are WhatsApp or Telegram secure enough to use for office communication?

It depends on what you mean by "secure enough". If unencrypted, unauthenticated messaging is secure enough, then yes. Otherwise, no.

WhatsApp's security model is secret and unverified. They claim to encrypt messages but don't give any ideas of how. The safest best is to assume no end-to-end encryption actually happens (which is probably the case anyway).

Telegram's security is more public, but is also a bit of a public disaster. This is discussed in another question, but the general idea is they made up their on cryptographic protocol which turns out to be an utter failure from a cryptography standpoint. While the team that designed the protocol is full of Math Ph.Ds and all the best intentions, their cryptography experience was severely lacking. As a result, they make impossible claims while failing to deliver on even the most basic security requirements.

If you're looking for a secure mobile messaging app, I would suggest TextSecure, it's open-source and therefore publicly verifiable, and also written by actual cryptographers who understand the technology they're working with. RedPhone, from the same group, adds encryption to voice calls.

As a lesser alternative, there's Threema: Each user's identity is tied to a public key which is used to decrypt the messages sent. The app design encourages in-person key exchange to improve security. Not open source, though, so the security is not verifiable.


Suggestions to avoid cookie-hijacking in a web application

You'd need to secure the GUID transmission (consider the possibility of a server posing as another server, or man-in-the-middle); I strongly suspect that this would rapidly evolve to something needing asymmetric encryption and, finally, a pared-down version of HTTPS. Since full HTTPS is already available, it seems a duplication of effort.

On the other hand, using a GUID (which acts, when all is said and done, as a [temporary] shared key) will not defend against the client being compromised (malware, 'black' forensics, possibly even social engineering depending on how the interface is designed). For this, you would need a local trusted escrow system - a sort of secure smart card, so that you cannot read and duplicate what's actually inside, while being able to prove to a third party (the server) that the data is there.

But at that point, would we really need cookies? We'd have a smart card with our user login data held securely; it would then be far simpler to link the session not to the browser, but to the username. The "remember me" function would be undertaken by you plugging in the smart card.

Another and easier possibility would be, as user lesto suggests, to store the privately agreed secret in a password-protected area - a "keyring", "portfolio" or "wallet" - just like form passwords. The user unlocks the keyring with a master password, then the browser can authenticate.

But the whole scheme can be implemented in a more direct way by forcing secure cookies to be stored in the secure area together with cached passwords. On receiving a cookie through a secure connection, the browser would request the user to unlock the secure area, find a cookie with the same name for the same domain already existing, and would then repeat the request, this time sending the expected cookie. From the user's point of view, he goes on a secure site with the "Remember me" option enabled, a browser popup appears requesting the master password, and next thing he knows he's logged in.

An attacker would have no way (weeeellll...) of accessing the HTTPS exchange, and if he were to seize the computer, he would find cookies and passwords in a AES-256 encrypted block for which he lacks the master access key.


Don't install anything. Windows 10 uses Defender antivirus, if you have not deactivated it. This message comes very probably from some bloatware that you have installed with some other software. If you follow recommendation in the message, you will very probably install virus.
What should you do?
Check what software you have recently installed and remove everything that you don't remember you have installed.
Find a CD or DVD or a (read only) USB stick with antivirus, reboot computer and start this disk with antivirus, launch antivirus and check your computer.


How to encrypt data using the iOS secure element?

The keychain already uses it.

From WWDC 2015:

  We also moved the KeyStore component from the kernel into Secure Enclave and it's that component which controls the cryptography around Keychain items and the data protection.

Source


Are there any security concerns for CGI scripts written in pure bash?

Buffer overflows aren't really relevant to bash. Something you do need to take care of is input validation. You need to validate all user input to prevent any form of injection.

You should have a look at the OWASP Testing guide as they cover all sorts of vulnerabilities relevant to web applications. It's largely language independent although the examples might be more focused on real programming languages designed to write web applications.

P.S. I really need to know: Why are you writing a CMS in bash?


Why would one disable a new TLS version by default?

I believe the reason for not enabling support for TLS1.1 and TLS1.2 in a TLS client by default was widespread TLS version intolerance among the installed TLS servers at the time. As Adam Langely (person in charge of server and client (Chrome and Android) TLS stack in Google, forker of OpenSSL into BoringSSL and author of Go's TLS stack) wrote in 2011:

Despite it being nearly twelve years since the publication of TLS 1.0
[RFC2246], around 3% of HTTPS servers will reject a valid TLS
"ClientHello".  These rejections can take the form of immediately
closing the connection or a fatal alert.  Intolerance to the
following has been observed:
Advertising version TLS 1.0.
Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1
or 1.2, around 3% for greater than 1.2).
Advertising a version greater than 0x03ff (around 65% of servers)
The presence of any extensions (around 7% of servers)
The presence of specific extensions ("server_name" and
"status_request" intolerance has been observed, although in very
low numbers).
The presence of any advertised compression algorithms

This issue with TLS version intolerance caused browsers to fallback retry, which caused Adam Langely to invent SCSV to protect against downgrade during fallback. TLS 1.3 had issues with proxies and switched the version negotiation mechanism to work differently and left two wasted bytes in the TLS record to say "TLS1.2", fixed forever.
To try to combat ossification and intolerant servers being deployed, Google's David Benjamin introduced GREASE, a system that injects fake never-allocated identifiers into options lists in TLS ClientHello to force TLS servers to correctly implement the required "disregard unknown values proposed by client and continue with the known values" behavior.


Before I had this concern, I was going to have it be www.domainexample.com?id=7, but any bot could check id=6 and id=5 to see if they've been shipped yet, and id=8 to see if there is a new order yet.

Generate a long, random ID. If you for instance generate a version 4 UUID it'll be unique and not guessable. Anyone with the URL can access it, but it's infeasible to guess the link.

The UUID is essentially the authentication in this case.


Kali Linux has tools under the category: Hardware Hacking. smali, apktool and android-sdk. These tools are specifically intended to target Android. Although, your question was more around the idea of remote exploitation, like that offered by Metasploit.

To clarify:

Phone number (Used to identify the SIM card)
IMEI number (Used to identify the phone)
MAC address (Used to identify the physical network address)

These are all selectors which uniquely identify you. They do not necessarily allow the device to be hacked. But does allow for correlations when tracking a user. The assumption being, device location equals owners location.

WARRIOR PRIDE code name for a pair of spyware kits that can be installed on the iPhone and Android-based smartphones. See, Angry Birds and 'leaky' phone apps targeted by NSA and GCHQ for user data which outlines the framework of WARRIOR PRIDE.

  DREAMY SMURF – handles power management, which according to The
  Guardian includes "an ability to stealthily activate a phone that is
  apparently turned off"
  NOSEY SMURF – "hot mic", turning on the microphone to listen in on
  conversations
  TRACKER SMURF – high-precision geolocation
  PORUS – "kernel stealth"
  PARANOID SMURF – "self-protection"

Now we have an idea of how real programs compromise Android and iOS. We can focus on the feasibility of using a phone number to compromise the device, which is to say, not feasible. Like with targeting an IP address, we will need open ports to exploit software, and most smartphones do not run servers which will have open ports. Unless you are aware of a character string set which the SMS client will give elevated privileges to (zero-day exploit), the phone number will serve as little purpose, other than being a unique identifier.

What about when the user updates an application, could I MITM and replace the real update with a modified update containing spyware? Absolutely, but this mechanism is either deployed over HTTPS or uses signed checksum validation, like that seen with APT. So, unless you break the public-key cryptography they are using, this is not an option.

What about crafting a website that will run malicious JavaScript (or PDF) code and give browser (or elevated privileges)? Possible.

  Safari on iOS 4.0.2 '.pdf' Local Privilege Escalation
  'Jailbreak'. An exploit like this would have likely, been detected
  by noticing the browser would crash (often a buffer overflow) when
  loading a PDF under certain conditions. CVE-2010-1797

I speak about this exploit in more depth How do hackers find vulnerabilities in closed source operating systems?.

I am brought back to SMS and malicious string sets, despite this not being an area where many scenarios have been documented its still an attack vector. So, I will focus on the social engineering perspective instead. Most people will open a well-crafted SMS, email, instant message without too much extra thought. This is how you can go from simply sending an SMS to directing the user onto a malicious website you control. Some messaging apps will display a URL by fetching the HTML title header and displaying that instead. Although, this is focusing more around the ideas of phishing (hacking the person) to compromise the device. Rather than hacking the device's software.


The token is always generated by the server, never the client.  You are correct that if the client generated the token, then the server could not verify that it was valid.   This is why every single CSRF mitigation scheme includes a token generated by the server.  So, since the server created the token, it always knows what the token value should be, and can validate that the client sent the correct token.


How can Google know that a Microsoft e-mail account is "not safe"?

Google is not going to reveal security algorithms to the public, so any guesses here are speculation.
My main guess is that Google sent 1 or more notifications to your alternate address, then decided it was abandoned because one or more of the following happened:

The notification was actionable, but you ignored it.  Possibly this could have been an e-mail asking you to reconfirm your account.
The notification was never opened (this is detectable, but not reliable).
Microsoft rejected Google's notification e-mail.  This could happen if the mailbox was full or if Microsoft blocked the account from receiving mail due to it being abandoned.


How do you defend specifically against attackers utilizing any or all of the commercial exploit kits?

This is such a massive question that I think the only answer is going to be to practice a defence in depth approach to security.  Start at the first point of contact and build up protection down the the very core.

In order to see what those type of kits are doing make sure you are logging and monitoring everything, this should give you some idea of what is happening.


My question is: for PCI DSS compliance is it possible to have a
  business justification for this incident, as the logs are lost, or
  what to do in this case.

You can try justifying why you lost the logs, but in all honesty if you can't maintain a suitable secure copy of them then its debatable whether you are (or even were) truely PCI-DSS compliant. (I don't know what levels you are intending to be compliant against)

That said: PCI DSS Requirement 10.5 and its
sub-requirements describe the methods that must be employed to protect logs:

10.5 Secure audit trails so they cannot be altered
10.5.1 Limit viewing of audit trails to those with a job-related need
10.5.2 Protect audit trails from unauthorized modifications
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter
10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device
10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

I have highlighted the ones that I believe you accidentally failed to comply with. Therefore I would make sure you update your policies and ensure that you have suitable controls in place to ensure it doesn't happen again. As long as you can demonstrate your corrective measures I think you will be fine.


Incident response and recovery from a security breach with unknown attack vector

You are viewing this from a security perspective and (I assume) from the perspective of a security practitioner. Assuming the company is in the business of making money, they will shut down the bare minimum required time because it will affect profits. IT will seldom have much input into whether or not they can remain offline while doing root cause analysis. Hell, most of the breach investigations I've been involved in, the systems are simply restored from backups, no investigation is done into what happened until they've been hit for the umpteenth time in a few months, and we are given almost nothing to work with in finding the root cause. Management cares about dollars, and though processes may change with things like GDPR I doubt this will change too much, except more IT staff will be fired after a breach. As for your question about 'excellent intrusion detection' capabilities, these are generally lacking too. If you read through the Verizon Threat Report: http://www.verizonenterprise.com/industry/public_sector/docs/2018_dbir_public_sector.pdf on page 10 it gives a break down on 'discovery', and its generally in the months to detect a compromise.


Why doesn't CVSSv2 consider XSS to have a confidentiality impact?

The answer is pretty simple. Since its an indirect effect of the XSS.
Example: A vulnerability that allows you to read the cookies would have a confidentiality impact.
But a vulnerability that allows you to inject XSS has a integrity impact (allows you to change the page), but as you can arbitarily change the page, to a malicious page that steals the cookies, the scoring does not take consideration to the indirect vulnerabilitys that are found.

Take for example this:
A vulnerability in a download script allows a attacker to replace the EXE that is being downloaded. It would have pretty high integrity impact.

But it does not have a confidentiality impact just because the malicious EXE being downloaded could leak information.

Same with XSS. This scoring is important as the remediation of the vulnerability is to solve it at its source (remove the possibility of XSS by filtering better). Improving the confidentiality won't solve this without incurring unintended side effects, and on top of that, the XSS would remain in the web application, causing the vulnerability to still be in effect (the CVE can't be registred as solved) because theres other risk's than confidentiality risks.

The CVSSv3 system does have a few other vectors added that compensate for this, thats why its also is changed in CVSSv3. (with the scope change metrics, which take in consideration if the effect of the attack happens somewhere else, and this can then be considered when mitigating the vulnerability)


Once your website has been hacked, you can not continue safely using it.  You must kill it with fire and restart over.  Wipe the whole thing, then re-install the application from a known-good source (or possibly restore from a known-good backup before you were hacked: but be sure that this predates the hack).

Once your website is hacked, there is no basis for trust.  The hacker could have left any number of backdoors (hackers usually do), and there is no way to detect them.  Pentesting is not going to find backdoors left by a hacker.  Pentesting is not the answer: you need to wipe and re-install.

Immediately after re-installing, make sure to update the software and lock it down so you don't get hacked again.


Security reason that Card Security Codes (CVV/CVC) are usually on the back of a card?

Older people will likely remember the older way credit cards were handled.

Carbon copy forms were the de facto method of proving to the credit card processor that you in fact did have the physical card present. Not only was it faster, but allowed for a very unique process to capture the credit card details.

This process involved the card, a carbon copy form, and a device with a sliding weight. The clerk would place the credit card on the device, overlay the carbon copy form on top, then slide the weight over top from one side to another. Any raised type would be captured, which included the customer information, and more critically the card number and expiry.

When the internet eventually came around, and phone transactions proved to be much more common place, CCV2 was used for these "card not present" transactions

These "2nd generation" CCVs were introduced to curb credit card theft, as it introduces a "something you have" for online/phone transactions. A malicious store clerk can't simply double swipe your card to clone it. Copying down the number becomes obvious, and can't be done with sliding the card through a reader. You can think of it as a simple PIN, tying a true card holder to the card in question. Only the card holder should have/know the CCV.

On to the major question, why do some credit cards have it on the front, where as some have it on the back?

There doesn't seem to be any standard to this, and seems to be a preference of the credit card issuer.

Visa will have the CCV on the back, and does make some sense. On first glace, someone can't see the security code without flipping over the card. There are countless cases of people taking a photograph of their card to "show off". On a AMEX, the CCV code is on the front, and this would prove disastrous. Do you recall the old method of capturing credit card details? Nothing on the back of the card was captured, this includes the CCV.

In reality, it doesn't really matter where the number is. If you have access to the physical card, you have the ability to view the CCV, no matter where on the card it is placed. Placing it on the front is more convenient as all the relevant details are in one place.

Credit card signatures are another demonstration, a bit less "technical" of security. Can you honestly recall the last time someone verified your signature against that on the card? How many people do you know have their cards unsigned? Arguably this is more secure than a CCV, but does require the card holder to be present with the card.

The future seems to hold that "rolling" CCVs are the next thing. Changing at a set time (every hour), these would prove to be much more secure than current offerings.


How to prove the Apache web server is not accepting connections anymore because of an denial of service attack (Slowloris)?

With .pcap file

Unfortunely, you can't ask for server status, while just looking for communication line.

But, you could count how many different connection are opened by one ip:

/usr/sbin/tcpdump -anr myfile.pcap |
    sed 's/^.*IP \([^:]*\)192.168.1.2.80:.*/\1/p;d' |
    sort |
    uniq -c

This will show a lot of

          10 192.168.1.8.36684 >
           4 192.168.1.8.39619 >
           9 192.168.1.8.39856 >
           4 192.168.1.8.39896 >
           5 192.168.1.8.40195 >
          12 192.168.1.8.40196 >
           9 192.168.1.8.52288 >
           7 192.168.1.8.58529 >
           9 192.168.1.8.58639 >
           9 192.168.1.8.58730 >
           6 192.168.1.8.58835 >
          13 192.168.1.8.58851 >
          12 192.168.1.8.58852 >
          10 192.168.1.8.58882 >

You could try to count how many connection per seconds, but how many maintened open connection is stronger.

Near real time

If  located on a proxy, a router or the server himself, you could trace real time connections with

tcpdump -ani eth0 host 192.168.1.2 and port 80 |
    sed -une '
      s/^\(.\{8\}\).* IP \(.*\)\.[0-9]\+ > 192.168.1.2.80: Flags \[S\],.*/\1 \2/p
    '

If too much output, you could count connection by sec, with a little delay due to uniq bufferisation and count

tcpdump -ani eth0 host 192.168.1.2 and port 80 |
    sed -une '
      s/^\(.\{8\}\).* IP \(.*\)\.[0-9]\+ > 192.168.1.2.80: Flags \[S\],.*/\1 \2/p
    ' |
    uniq -c

Next step

If based on Linux, you may start to play with iptables to build triggers for this kind of attacks, have a look there:

How to best defend against a “slowloris” DOS attack against an Apache web server?  @ serverfault.com


Your scheme is both not feasible and not secure.

  1) instead of using the 26 characters in English I’ll use the
  1,111,998 characters in Unicode.

What does this change in terms of security? It won't change the fact that most characters in the messages will be A-Z.

  2) some characters will select in advance and will never be used in
  the encrypted message. The selected characters will be inserted as a
  distractions in the encrypted message (the receiver will know to
  ignore them).   ...   The receiver will add the missing “O”:

That just won't work. There are infinite possible messages you could generate by adding a number of characters at some places, and the computer is not intelligent. While a hash could help a bit, I guess with your restrictions you can't have one (and this is out of the scope of a pure "encryption" anyways).

  The receiver will scramble the letters randomly until the message
  makes sense (I know this is sounds like a brute force, but in my case
  this is fine):

Again, not possible with some checking method. And if you have one, eg. 20 characters are 2432902008176640000 possibilites. Not fine.

  You can’t do a letters statistics attack since we have a distraction
  letters.

So what? This does not change much.

  And the fact that we have a map and not a shit and over a million
  letters instead of 26 make every “guess” of one letter almost useless
  for the others (specially in short messages).

Again, it won't change the fact that most characters in the messages will be A-Z.


Is there value in pen testing iOS apps that will operate within a MDM environment?

It's all about risk reduction. MDM and testing cover different types of risk. You need to figure out what risks will be covered off by testing that can't be addressed by the MDM. Think: defense in depth.

For instance, is there info leakage? Are user credentials exposed? Is data accessible from the app to storage so that the user can download? MDM might address some of these issues (depending on how it is configured), but what happens when MDM fails? Or if someone configures the MDM differently for themselves or an exec (gosh, I've seen that too many times).


Best practices to prevent logging of LDAP credentials by intermediate apps

So how does one make sure that the internal tool does NOT see the credentials but still be able to authenticate the internal tool against the LDAP server?

Many protocols exist to provide authentication without sharing user credentials with the application that's granting access. Several companies (Okta, Duo, One Login) provide tools to help implement using these where they are the application that sees user credentials and other applications get the identity information via whichever protocol is suitable for them.

It's definitely best to have users redirected via OAuth2, SAML, etc. than to provide their password directly to any application that may be used.


Could HTTPS redirects to HTTP be blocked in future?

An application can naturally leak sensitive information,  such as an session token over an insecure channel using a HTTP 302 redirect. But this could happen in an attack,  "hey click on http://authsite.com",  which may make the browser send an HTTP request in the clear.

An application can protect session tokens using the secure cookie flag, which instructs the browser not to send the session token over an insecure channel.

Additionally, there is HTTP-Strict-Transport Security (HSTS),  which will force the client to use HTTPS,  even if there is a careless 302 redirect to HTTP.  HSTS was created in a response to the SSLStrip attack.

All web applications must deal with insecure transmission, and it is a common server-side defect on the internet today.  In the near future,  chrome will use a broken lock icon on webapps that leak sensitive information.


Victim system's internet connection slow after ARP spoof?

From reading this article it appears that nemesis just poisons the arp cache of the victim and gateway to cause them to forward packets to your machine (the middle man).

You need to enable IP forwarding (see the previous article or this one for more detail on IP forwarding) on your machine to get the redirected packets forwarded to the correct systems.


Outgoing messages while under massive denial-of-service attack

Any protocol that guarantees reliable delivery would suffer under a massive incoming DDoS. UDP per se won't, but QUIC, like TCP, would.
Some of this negative impact — under certain circumstances — could be handled with selective acknowledgment or different congestion control mechanisms, but in general, you'll need to drop acknowledgment completely.
In real gaming tournaments over the Internet a lot of effort is invested to make sure that the IP addresses of the competing teams don't leak to each other. A centralized server or a network of proxies are used to ensure that.
A fun story: there once was a bug in Skype that leaked the IP addresses of the Skype users. As a result, Skype was banned from most of the major gaming tournaments, and firing off a Skype window while in the game was enough to get you immediately disqualified from the competition.


Do not give the keys away from your owned and maintained hardware. If you don't have a root on your computer, user Smart Card (or Yubikey).

As already said, nothing protects your keys (or data) from physical access and root user. Not even SELinux (root can do everything, if is unconfined!). Cryptography does the job only partially (encrypted keys can be brute-forced, but it is not feasible if you have passphrase strong enough). But trusted hardware can not be brute forced and you know exactly when it is used (requires confirmation, pin, whatever).


Is RDRAND used in a safe way by Windows 10?

In short:
Maybe (see the Conclusions).

Documents
Windows's default random generation process is described in considerable detail in its Common Criteria and FIPS 140 validation documents.
For Common Criteria in the Windows "Security Target" documents.
For FIPS in the Microsoft's "Kernel Mode Cryptographic Primitives Library" and "OS Loader" ones.
Do get all three of them, there are details in the Common Criteria documents absent from the FIPS ones, and vice-versa.

These are the most recent versions at the moment of writing, which apply to Windows 10 Fall Creators Update:

Common Criteria Microsoft Windows 10 and Microsoft Windows Server (Fall Creators Update) - Security Target (2018-07)

FIPS 140-2 CMVP #3196 - Microsoft Kernel Mode Cryptographic Primitives Library - Security Policy (2018-09)

FIPS 140-2 CMVP #3194 - Windows OS Loader - Security Policy (2018-09)

I also found this paper from 2015 which analyzes the topic in some detail:
Windows and Linux Random Number Generation Process: A Comparative Analysis.
It treats Windows 8, though  (for example, you might notice that it mentions the infamous Dual_EC_DRBG, but that was removed in Windows 10).

Details
Since StackOverflow usually doesn't like links, I replicate here most of the details:

| Boot-time seed
First, a 512-bits boot-time entropy seed is generated:

Entropy is gathered from the following sources, when they are available on the computer:

The contents of the registry value HKLM\System\RNG\Seed, which is written by the Kernel
Mode Cryptographic Primitives Library (cng.sys) during its normal operation.
The contents of the registry value HKLM\System\RNG\ExternalEntropy, which can be
populated by system administrators. This value is overwritten after reading, to ensure that it
is not reused.
If a Trusted Platform Module (TPM) is available, the output of a TPM_GetRandom call to the
TPM.
The current system time.
The contents of the OEM0 ACPI table in the machine firmware.
If the CPU supports instructions for the RDSEED ( used when available) or RDRAND (used if
RDSEED is not available), the output from RDSEED or RDRAND.
The output of the UEFI random number generator.
The CPU timings.

These inputs are then combined using SHA-512, and the entropy source is conditioned using a
non-Approved RNG. From this NDRNG, a block of output bytes is passed to the Windows kernel
at boot time

source: FIPS OS Loader
Notes:
I'm not sure what they mean with "conditioned using a non-Approved RNG".

| Entropy pool
At runtime, at all times, there is then a "Windows entropy pool", which

is populated using the following values:

An initial entropy value from a seed file provided to the Windows OS Loader at boot time (512
bits of entropy). (the boot-time seed)
A calculated value based on the high-resolution CPU cycle counter which fires after every 1024
interrupts (a continuous source providing 16384 bits of entropy).
Random values gathered periodically from the Trusted Platform Module (TPM), (320 bits of
entropy on boot, 384 bits thereafter on demand based on an OS timer).
Random values gathered periodically by calling the RDRAND CPU instruction, (256 bits of
entropy).

source: Common Criteria

The Windows DRBG infrastructure located in cng.sys continues to gather entropy from these sources
during normal operation, and the DRBG cascade is periodically reseeded with new entropy

source: FIPS Kernel Mode
Notes:
I was unable to find out how these sources are combined, if they even are.
Maybe they use the same system as the boot-time sources, maybe they are just laid out one after another and taken up in turns :o .
The 2015 paper seems to assume that they're combined in the same way as the boot-time seed, but I couldn't find any sources to substantiate that and I think it's likely that the authors jumbled up the two by mistake.

| BCryptGenRandom
The recommended function for obtaining random data, BCryptGenRandom, then works by using this pool
as a seed for a NIST SP 800-90A AES-256 counter mode based DRBG.

Conclusions
It might be a good system, and so RDRAND might be being used in a good way, but until someone clarifies if and how the entropy pool sources are combined, I don't think we can really tell.
It would be very surprising if the pool sources were not mixed-up, but then again... maybe not so much.
In any case, I must emphasize that I'm not really an expert in this field, I might well have missed something and it might even be that it wouldn't matter if the sources weren't mixed.
I meant to only reports the documents that I found, but as I noticed these things I thought I would mention them as well.
Wait for the opinion of some qualified cryptographer before drawing a conclusion (and most of all, of course, try to find out how this pool really works).

Notes

Of course keep in mind that this is just the recommended way to get random data, any application is free to use what it wants.

Note also that as these certifications might (I'm not certain) apply only when Windows is running in FIPS mode, this information might be guaranteed to be valid only when that mode is enabled.
One sure difference is that only in FIPS mode there are some self-tests performed on the DRBG on start-up and during a reseed, as mandated by SP 800-90A (but there are probably few circumstances in which they would be useful).

Of course this is always a closed-source system, updated all the time, so we can't be a hundred percent sure of what it really does (unless we don't reverse-engineer our own and block further updates).

P.S.: Long links look really bad with the new theme


If you've been compromised once, are you more likely to be compromised again?

No. At least not for the reason you state.

You're confusing a single compromised user account, e.g. because someone figured out your password, with a compromised application platform. If I get access to your facebook account, that doesn't mean that I get access to the underlying machinery. And if I did get access to facebook's innards, it wouldn't just be a problem for you, but likely for every facebook customer. So while its true that with such access, I could keep compromising your privacy etc, that would also apply to lots of others, so you wouldn't technically be more likely than anyone else to be compromised, and being compromised yourself wouldn't have anything to do with an individual breach of your account.

Of course, if you used the same password on every online service and I found out what it was, then I could compromise every one of your accounts. But I assume that's not what you meant.

Also, if I compromised your mail account without you noticing, I could get continuous access to most your online accounts, even if you changed your passwords on them, because I could use their password reset functionality thanks to the access I had to your mails. But you'd notice sooner or later, because I'd need to change the passwords in order to gain access, so you'd keep wondering why your passwords didn't work.


Issues of using HOTP w/ iteration window

The "OT" in "HOTP" means "one-time". This is true only if the server indeed rejects passwords corresponding to a counter value which is not greater than the last confirmed value. Having "a little margin" here would mean accepting that a given password is accepted twice, the very thing that HOTP tries to prevent.

This is all based on the idea that the HOTP owner uses his passwords sequentially; there is never a situation where the owner would have any interest in using a password which is not the last one that his password-generating device produced. Correspondingly, if the server received at some point the password corresponding to counter value 1567, then the server knows that the owner's device has gone to value 1568, and any attempt at using, say, password 1565 would be a sure indication of foul play.

The "window" is toward the future, because the device owner may have inadvertently pushed on the button a few times without noticing it, so maybe the next password will correspond to counter value 1575, not 1568, and the server will still accept it.

In other words, the window behaviour as specified in RFC 4226 is the margin you need. There should be no need for any margin in the other direction; if there is such a need, then you are probably misusing HOTP badly.

Edit: if you have several servers consuming one-time passwords from the same source, then I strongly hope that you route all such passwords to a single authentication server, that maintains the counter value. (If this is not the case then you have much bigger issues.)

If you just fear that two such OTP may reach the authentication server "out of order" then you can indeed make things a bit looser without compromising security, but it requires some care. The important property of a one-time-passwords system is that each password value should ever be used once. The counter value, with the semantics explained in RFC 4226, is a cheap and efficient way to maintain these semantics: the server only has to remember the last seen counter, and that's all.

However, you can make the authentication server remember the actually used password values. This can be a "backward window": at any time, the server has a current counter N, which is the highest seen counter value, and remembers all see passwords in the N-9 to N range. With such a window, the server can receive passwords slightly out of order: a password will be accepted if its counter M is greater than N, or is in the N-9 to N range and was not seen yet. The programming on the server is slightly more complex, but not unsurpassingly so.

Important note: the "backward window" is safe in the case of HOTP, but that does not extend to just any "one-time password" scheme. This is safe for HOTP because HOTP is a MAC computed over a counter value -- it relies on the counter not to repeat itself, but not on the possible counter values being used in numerical order. The same would not be true for one-time password schemes which use hash chains (where each OTP is a hash of the next one). What I say here is only for HOTP.


Should user be authorized in site after following email change confirmation URL?

If you do not have an authorisation step in the confirmation, then if the user mistypes the email and an unauthorised person gets the link and confirms, then the unauthorised person can gain full access to the account through the "forgot password" function.

This happens to me all the time. People use my email address by mistake when signing up for things. I can confirm the email, and then could then reset their password.

You would think that the user would notice, but I get a dozen emails a day destined for other people who have not realised that a service is sending me their info. (I can't make a change on my own because that would mean gaining unauthorised access to the user's account).


How often ciphers are used through an IPSEC session

which integrity can be checked within the payload using a simple CRC

Not a simple CRC. Classic IPsec cipher suites usually use HMACs based on cryptographic hash functions (e.g. SHA-1/2) so verifying and creating Integrity Check Values (ICV) for every ESP packet will require several applications of the negotiated hash function.  However, there are alternative integrity algorithms based on encryption algorithms (e.g. AES-XCBC-96) if you wanted to avoid the use of hash functions (or have hardware acceleration for AES). And there are, of course, combined-mode ciphers (aka AEAD) e.g. AES-GCM, which generate/verify ICVs while encrypting/decrypting the packet in one pass.


Is HTML5 input pattern validation sufficient (or even relevant) for client-side validation?

From a security perspective, you need to revalidate everything on the server. This will always be the case, no matter how pretty and advanced HTML5 features become. You simply can not trust the client. You have no idea if it will follow the HTML5 rules or not. You don't even know if it is a browser.

So should you validate the whole form with your own JS client side before submitting it, even if you use the HTML5 features? From a security perspective it doesn't matter. Client side validation have zero security value anyway - see above - so from a security perspective you might just as well not bother doing it at all.

Client side validation is purely about user experience. If your own JS validation or HTML5 built in makes for the best UX is an interesting question, but it is not on topic here.


Advantages of http CONNECT method over TLS

The main advantage of accessing the proxy with TLS is that somebody who can sniff the traffic between the client and the proxy cannot see sensitive or private data. This means of course the domain the client is accessing (i.e. endpoint of the requested tunnel) but also any credentials used for proxy authentication.

Additionally TLS might also protect the payload between client and proxy. The payload of CONNECT is not always HTTPS: For example plain WebSockets (i.e. ws://) will use CONNECT when a HTTP proxy is involved and WebRTC might also fall back to it if no better way (i.e. direct UDP connections or using TURN) is possible. But note that this protection will only happen between client and proxy and the connection between proxy and will not provide any additional protection between proxy and server.


How to safely watch pirated movies, open infected files?

The theoretical answer is you cannot.  If the attacker has a set of exploits that take over the operating system then they can write to many places beyond RAM or the hard drive.  These places include but are not limited to: the UEFI (for example http://blog.frizk.net/2017/08/attacking-uefi.html), GPU (for example, https://www.extremetech.com/computing/205270-proof-of-concept-gpu-rootkit-hides-in-vram-snoops-system-activities) intel management interface (for example, https://boingboing.net/2016/06/15/intel-x86-processors-ship-with.html).

On a practical level, if you insist on trying, you have two choices: you can use a cheap device like an Amazon Fire Tablet (still rootable, and still able to attack your router and other devices from the inside), or an IoS device, which is also still attackable, but the attacks are rare, and unlikely to be wasted on you, unless you happen to work for the GRU, CIA, a human rights org that's annoyed a government, etc, etc.


Can you access Google Drive documents if you have the absolute path to the file?

The answer to the main question is NO. Each individual file has its own permissions.

  Choose an appropriate sharing setting — Private, Anyone with the link, or Public — for your files, folders and Google documents.

Source: Google

Google generates an ID based on the sharing permissions and just authorized sessions (to the Google IaaS) are able to retrieve the file.

  Downloading the file requires the user to have at least read access.

Source: Google


Some attacks to think about:

Tricking the failed_logins by clearing your session id.  Enumerating accounts by trying to lock out existing accounts.  DoSing administrative accounts by locking them out with failed login attempts.  Enumerating login names with the forgotten password feature or with registration,  or insecure direct object reference. Spoofing your ip address by supply a x-forwarded-for http header element.

Broken session management:  Session Riding (CSRF), Session Expiration, Session Fixation, Problems with Cookie Domain/Folder Scope, Storing Session ID's in plain text in the database,  Insufficient entropy in session ids.  Not setting the "secure" and "HTTPOnly" flags.  Clickjacking.  OWASP A9...

Did I miss anything?

YES


What *actually* is a Java applets vulnerability?

Classes of Java Applet vulnerability

Vulnerabilities in the Applets themselves

This would include issues with how the applet is written, such as:

Backdoors
Cross Site Scripting
Cross Site Request Forgery

Vulnerabilities in the Browser and JRE

This would include issues with allowing the running of Java applets, such as:

Ability to track users
Ability to perform malicious actions
Sandbox escapes

Why are Java applets so bad

Trying to sandbox the applets is hard, and as such there will be edge cases allowing sandbox escapes. As most of the things that web pages need to do can be done without adding the extra vulnerabilities, it makes sense to try to disable applets, as this reduces the attack surface.


Actually it is very common to not support SIPS.

  user name and password will have to be transmitted unencrypted

SIP uses Digest MD5 for authentication which is a challenge response protocol where the passwords are not transmitted in clear text. Thus cracking the password by sniffing the connection is not possible unless the attacker has access to a huge number of authentications done by the same user.  Brute forcing the password is usually more successful.

Using Digest authentication also means that the password need to be stored by the server in clear text or in some equivalent form or reversible encrypted, i.e. the usual one-way hashing is not possible.


Which CA currently issues certificates for Wikipedia sites?

There is an ongoing task at Wikimedia to use two separate CAs:

  This was originally on our long-term radar as part of the (forever-stalled and in-discussion!) [H]PKP ticket: T92002 . The recent GlobalSign issue has highlighted the need to break this out as a higher-priority action we should take on independently of that.

  We need to obtain our "unified" cert from two vendors with the same SAN set, in both ECC and RSA forms. Ideally the annual renewal time for each should be at least slightly offset (~1 month?). We'll puppetize the deployment of both keys to all of the cache clusters, including live OCSP staple fetching for both from everywhere.

  We'll puppetize such that VendorA's certs are live in one set of datacenters and VendorB's are live in another under normal conditions. With both in active use, we'll be ensured they're both normally working properly on fine details like browser compatibility, OCSP, PKP, etc. By splitting on regions (rather than other arbitrary splits), we avoid issues with individual clients commonly bouncing between two disparate certs and the effect that may have on performance-related issues.

On January 5th (today), a change rolled out to use both certs in normal circumstances:

  These are now deployed (digicert in esams, globalsign elsewhere). Pending closing this until we document switching off either of the certs...

So in summary: yes, this is expected and not indicative of a problem.


Who can se what I search for on different search engines?

One of the most useful explanations I've found is the EFF's page on Tor and HTTPS.  It's an interactive diagram that shows who has access to what information about you, normally, when using one of Tor or HTTPS, or using both.  It is a bit U.S.-centric; laws in other countries may affect what organizations can legally gather.

One limitation to what that page covers is that it only discusses what an observer can find out about a single HTTP request.  When discussing things like tracking your search results across multiple days, there's more to talk about in terms of deanonymizing traffic.  That is, if I know someone searched for "foo" and I know someone searched for "bar", do I know those were the same person?  IP is the most obvious way you can be tracked, and persistent cookies is another well-known option, but there are also plenty of more sophisticated options like HSTS super cookies and fingerprinting (more here and here).  It's even easier if you log in to sites (Are you logged into a Google account?  A Facebook account?).

There's a lot more to talk about, more than will probably fit in a Stack Exchange answer.  If you have more specific questions, I'd encourage you to ask those separately.

The very short tldr is "yes, companies and governments (yours and others) know what you're doing".


How do I safely inspect a suspicious email attachment?

It could also be:

3. HTML page with JavaScript code attempting exploit a vulnerability in your browser.

4. HTML page with an embedded Java applet attempting to exploit a vulnerability in the JVM

5. HTML page with an embedded Flash file attempting to exploit a vulnerability in Flash Player

6. The email itself, before you open the attachment could try to exploit a vulnerability in your email client

There might be other possibilities.

For this purpose, I have the following setup:

Virtual Machine using VirtualBox. No network access.
I have a snapshot saved for the VM after a fresh OS install.
I also take two snapshots with What Changed? and TrackWinstall.
I copy files only in the direction Host -> VM, using a free ISO creator.
I create the .iso file and mount it. Then I can have all the fun I want on the VM itself.
I usually run the malware and study memory usage, CPU load, listening ports, networking attempts.
I check the changes to the OS using What Changed? and TrackWinstall.
Finally I restore to the fresh snapshot.

The reason I have the whole setup is because I like to run the malware and see what it's trying to do.

Update:

I was talking to a colleague who performs malware analysis as a hobby and he told me about his setup, it might be different that what you might want for an occasional .html attachment check.

Old PC with a fresh OS install.
After installing the needed tools he takes a full-disk image using Clonezilla Live.
What Changed for snapshots comparisons.
The PC is connected to the Internet through a separate network.
Whenever he finishes working on a sample, he reboots with Clonezilla and restores the full-disk image.


Can I completely impersonate another wireless device?

What if I want to communicate completely anonymously?

Wireless is relatively anonymous from the perspective that you, as a person, won't be easily identified unless your traffic gives you away. That said, your location is identifiable using triangulation and your hardware device ID (MAC) will identify the device used unless you're able to override it.

  I am curious if I will be able to also transmit and receive as if I am an already connected device. Is that possible?

Yes, sort of. If you can inject successfully and receive successfully you can pretend to be a device already on the network but to fully emulate it isn't reasonable to do. It depends on what you're trying to accomplish.

  Is that actually anonymous?

See above. Depends on you and what you're attempting to accomplish. The amount of anonymity that is possible depends on how you behave on that network. Simply listening is completely anonymous as you're not sending anything out. Interacting in any way is less so and the amount of anonymity will drop as you interact more and more.

  How will the legitimate host react to packets it is not expecting?

Depends on the packets. In many cases you'll get a RST response or nothing at all. If you're attempting to modify or affect an existing connection that can be difficult at best. TCP has a number of controls in place to try to prevent this.

You can inject ARP packets to tell the system you're someone else on the network in an attempt to intercept traffic and in some cases this can work for you to man-in-the-middle a victim system's connections. As long as your device acts and behaves like the router the victim computer expects you could insert somewhat smoothly into the stream.

If this doesn't address what you're looking for please try to clarify the question and make it more specific.


No system will be 100% secure. I think that some authentication providers (such as Facebook) will force you to use TLS and will only allow redirections to https:// sites. If your connection is not secured using TLS, an eavesdropper will be able to see any tokens exchanged in the OAuth authentication process. With Let’s Encrypt available for free, there is really no good argument against even the most basic TLS solution.


XSS vectors in img src and background-image url

No, in modern browsers no XSS is possible via the style or src attribute of an  tag.

So neither of these would execute the JS code in any up-to-date browser:

Support for Javascript in CSS attributes has long been abandoned. You can find some older references about it here.

Analysis of your example code

location.hash always starts with a # symbol. Since this character is illegal in JS and not a valid beginnig of a new URL, no XSS would be possible in the first place. (For instance, eval(location.hash) always produces a syntax error.)

Let's assume, you ignore the # and location.hash could really contain any string you want.

Then this security check is flawed:

(location.hash.indexOf('javascript:') !== 0)

An attacker could still construct a URL starting with JaVaScRiPt:. Also, it's risky to assume that no implementation would ever allow leading spaces or control characters (e.g. \t\x00javascript:). And what about URL-encoding? A payload starting with javascript%3a would pass your filter. Also, do you want to allow the data: protocol? If you like to restrict the URL to absolute locations, you could whitelist the beginnings http:// and https:// instead of blacklisting javascript:.

This is fine:

img.src='some/local/path/'+location.hash;

Even if the src attribute was susceptible to script code, your prefix some/local/path/ ensures that it cannot be turned into a JS URL. However, an attacker could specify any relative path to an image file on the same server, which you might find undesirable.

NB: This is about constructing malicious javascript: URLs. If you want to use user-controlled values like location.hash for HTML output or a different context, you have to properly sanitize the string.


Your admin got it real wrong (or there was some translation mishap).

TLS 1.1 and 1.2 fix some issues in TLS 1.0 (namely, predictability of IV for CBC encryption of records). It is possible to work around this issue in TLS 1.0, but it depends on how hard the implementations work at it. So, in that sense, TLS 1.1 and 1.2 are more secure than TLS 1.0, since they are easier to implement securely.

The so-called "heartbleed" is not a protocol flaw; it is an implementation bug that is present in some OpenSSL versions (OpenSSL is a widespread implementation of SSL/TLS, but certainly not the only one). When an OpenSSL version has that bug, it has it for all protocol versions, including TLS 1.0. Thus, when heartbleed applies, it equally applies to TLS 1.0, TLS 1.1 and TLS 1.2. When it does not apply, well, it does not apply.

The source of the confusion is that your admin (or his sources) does not appear to understand or conceptualize the difference between protocols and implementations. TLS 1.0 and TLS 1.2 are protocols described in relevant standards (RFC 2246 and RFC 5246, respectively). A protocol says what bytes must be sent when. An implementation is a piece of software that runs the protocol. OpenSSL is an implementation. It so happens that the "heartbleed" bug occurs in the implementation of a relatively new protocol feature (the "heartbeat extension") that very old OpenSSL implementations don't know about. Thus, very old implementations of OpenSSL don't suffer from heartbleed (though they have other serious issues, being very old). The same very old implementations don't know about TLS 1.1 and TLS 1.2 at all. Thus, in the mind of your admin, the two independent facts coalesced into a single (but flawed) mantra, that wrongly says that heartbleed is a security issue of TLS 1.1 and 1.2.


Looking for a CIS Bechmark Tool to run against Amazon Linux 2016.09

Lynis is the open source alternative which not only does CIS but few other compliance tests as well.

The ability to modify the code to generate custom reports is handy for large number of systems.


Store a secret on a Windows computer so that even an administrator cannot access it

To be honest, that's probably not even the weakest point in your scheme.  If I was the admin trying to get the secret, all I'd do is decompile the app that's requesting the secret (to see how it does it), and just build a quick .exe that politely asks your service for the secret.  I mean, your secret-keeper doesn't really have any way of knowing whether the app requesting the secret is authorized to have it.

I think the short answer is: you really can't do what you're asking.


Risks of deploying a server authentication certificate along with a client application

You are publishing a certificate for https://app.example.com along your app. Thus this private key is no longer "private". Someone will find out and publish it. This will lead to the CA revoking your certificate for app.example.com (they MUST revoke it). This has happened in the past, you are not the first one to have such idea, companies like Cisco, Blizzard, EA, Spotify, mega… used to do this.

This is more a procedural issue, but it will bite you quite quickly (do remember that the CA have 24h to revoke it once they are made aware that the certificate is compromised).

A MITM could extract the certificate from your app and impersonate app.example.com on someone which don't have the hosts entry, but it isn't worth listing the risks with that given that your approach won't work for too long.

If you really need to use a certificate for https://app.example.com, create a certificate locally (so that each client have a different certificate), properly constrained, and add it to the client certificate store.

Plus, obviously, the server running in the client shouldn't do silly things such as allowing launching arbitrary programs, or exfiltrating client files. That local server is a security boundary, so it shall be very careful validating any input…


What stops a hacker from installing its own CA certificate?

Installing a "trusted root" on a victim's computer requires local administrative rights. If the attacker can do that, then he has already won.

Hacking into the CA's server to obtain a fake certificate is a way for the attacker to be able to masquerade as various "trusted" servers and issuers (e.g. to make fake "signed" OS updates), in order to breach into user computers that are not easily reachable otherwise (Trojans work for some users, not for all). It is all a matter of escalation. A CA server is very sensitive because hacking it gives (more or less) automatic entry to millions of other computers.


Security Implications of PHPCSS Files ( Dynamic CSS using PHP )

I have been doing exactly this for many years on several websites.

This is no more and no less secure than using PHP to build an HTML page.

Make sure you sanitize/validate any user-provided inputs (as you would do for handling user input on a regular web page), and there's no reason not to do what you are doing.


Why must I register a new phone for 2FA services? The number is the same, isn't that enough?

First, there are actually multiple ways how 2FA might work, the maybe simplest way is to receive a SMS with an access code form your service during each of your logins. While this is a bit less secure because it could be intercepted, this way you should not be required to update your 2FA settings if you switch your phone while keeping your SIM.
Another way how 2FA could work is by installing a token generator on your phone, an app from your service provider. For instance, a Time-based One-Time Password generator. The point here is that your phone can generate a token at anytime even without network access.
Since such a generator works the same on all phones and is a deterministic algorithm, some code or key on your phone is required to verify it was indeed generate on your phone. If the app would use some thing like your calling number everyone knowing it, might generate a valid code for your account. Also serial numbers of your SIM or hardware have similar flaws. So a better way is to have a random key only available on your specific phone and in some sort at your service (for verification). Btw this usually makes not only losing your phone an issue but also deleting just your generator app.
However, such a key means that changing your phone necessarily means that you would have a different installation of that app on your new phone with a new key (or non). And for security reason, your old key shouldn't be available to any syncing service, so there rather should be no mean to copy it over.
Reason why the recovering of your account is that complicated, is that it is by definition a way to by-pass the 2FA. That means if there were an easy way for your to recover it, there is also an easy way for the bad guys to get access to your account while you are using 2FA. By entirely denying this (like Github), it guarantees for your that once you enabled 2FA there is hardly a way for others to by-pass it.


Can malicious code be contained outside the filesystem on a USB drive?

A USB device with "manipulated firmware" can sure do evil things. For an extreme case, see this answer: the USB device may tell to the OS "hey, I am the FireWire-to-USB converter X.Y, please download my driver from your vendor, then grant me full DMA access when I say so". Though theoretical yet, this is not science-fiction, and it sure is scary.

For more mundane setups, including some which actually occurred, see this answer.

Even if the USB device is "just" a USB drive with an honest firmware and an empty filesystem, it still has a boot sector (first sector, the one containing the partition table) which is code; but that one will be activated only if the user tries to boot his machine over USB (this worked wonders in the floppy disk era, because most machines would try booting off the floppy if present; nowadays, if almost all PC can boot off an USB drive, most will not try by default).


Managing vulnerabilities in continuous delivery

The answer to this question, as with so many in security is, it depends on your threat model.
What I'd say is that some container vulnerability scanning tools are slightly unusual in that they flag "unfixable" issues for which there is no patched version in the distributions repositories, by default. For example Synk, Trivy, Anchore and Clair, all default to this approach.
Standard Vulnerability assessment tools used for Virtual machine or physical server VA such as Nessus, do not flag CVEs if there is no patch available, by default.
So you have a couple of choices here :-

If your container VA tool has the option, tell it to ignore unpatchable issues (For example, Trivy has the --ignore-unfixed option.  For most setups, this is probably the correct choice

Assess each unpatchable issue and decide whether it's relevant to your environment, then add it to a list of "thigns you're not worried about" if it's not.

Compile packages manually to address the CVEs.

One other point to make is that there's a couple of ways of reducing the incidence of these issues

work to minimize the number of packages used by your container images. Things like multi-stage builds are good for this

If possible, consider using things like using static binaries in scratch images, which will largely remove this issue (although it does come with it's own challenges)


Reverse engineering and buffer overflows: zero to hero

I think the standard, at least back in the 90's was "Smashing the stack for fun and profit" from phrack magazine.


Does using FreeDNS introduce a security risk?

DNS is only used to resolve domain names to IP addresses so there is certainly the risk that the domain can be hijacked if your DNS provider turns out to be untrustworthy.

I think the question you really want to ask is what a person can do by hijacking a domain name (i.e. control the DNS records). The problems or risks that can arise are very similar to that of DNS poisoning/spoofing. Here are few examples of things that can go wrong.

Get SSL certificates issued for your domain. This could lead to a MITM attack on any secured websites you host on that domain.
MITM any unsecured website you host on that domain.
Redirect your domain to their own server to host spam. This can damage your search engine rankings.
Redirect (and hence read) email sent to the domain.
Redirect SSH connections to a server under their control (this can lead to a MITM attack if you don't verify the server host key).

Of course, this is a non-exhaustive list but notice that none of these allow the registrar to directly eavesdrop on any communication between you and the server. Rather it allows them to redirect the hostnames to servers under their control and you won't know unless you inspected the resolved IP addresses carefully.


Is it secure to use a part of the key as IV in AES?

Is it safe to use a part of the key as IV and what is best practice?

In a word. NO.

IV is a fundamental part of cryptography that forms part of the essential element of randomisation. The use of a non-cryptographically random IV that is static or otherwise predictable as part of your encryption process means that you are potentially weakening the randomisation element of your chosen cryptographic algorithm.

The reason example code frequently uses fixed IVs is for that very reason. It's example code, commonly found in books or on websites.  The authors have a need and desire to keep the example code as short as possible, so fixed IVs are used on the unwritten understanding that the reader has a sufficient grounding in the principles of cryptography to know they should be using random IVs in real life.

If memory serves, Bruce Schneier has an entire chapter on IVs in one (or more) of his books. That would be an excellent starting point if you really want to get into the detail of the matter.


If a message can be repeated, is that confidentiality, availability, or integrity?

Replay attack is a standard term for this type of attack. You are right that the security property that is broken by this attack falls under the umbrella of integrity. It is an attack on the integrity of the communication as a whole. The integrity of each individual message is preserved, but not the integrity of the whole sequence of transmissions.

The attack may cause some effect in the recipient that in turn compromises the availability or confidentiality of other assets, but these compromises are not caused by the replay attack in itself. For example, if an actuator overflows a limit because it accepts too many messages to move in the same direction, and the reason the attacker could send these messages is that the communication protocol is not protected against replay, then an attack compromises the availability of the actuator, by compromising the integrity of the communication as a step in the overall attack.


Is it possible to evaluate the connections that Tor Browser makes when we access a website?

JavaScript cannot bypass proxy settings in Firefox. The only way it can is by exploiting a new bug in the JavaScript engine which allows complete control over Firefox, allowing the proxy settings to be ignored. Features that are able to bypass the proxy settings at will include Flash and Java (unrelated to JavaScript), and those are not included in Tor Browser for that reason.

Detecting a bypass attempt can generally only be successfully done if you are detecting a successful bypass attempt. Assuming you are using Linux, this can be done safely by using iptables, which is the frontend for the system's firewall. If you make Tor run as its own user (for example, by using Tor in a distro's repository), you can set iptables to deny all network connections which are not coming from the dedicated Tor user. Violations can then be logged.

The Tails live operating system does this. All applications on Tails are configured to only go over Tor, and any applications which try to connect to the internet directly (whether due to being misconfigured, or having been compromised) will be blocked, with logs sent to the system log.


SHA1 - S/MIME and CRL validity after deprecation?

The general situation looks like this:

A signature relies on some certificates, that assert the ownership of public keys. Certificates are primarily designed to be validated now (e.g. the certificate's date of validities are compared with the current date).
These objects tend to degrade over time. CRL expire (usually rather fast). Certificates expire; when a certificate has expired, it ceases to be included in CRL, so even if you can download a new CRL, you won't be able to know whether the now-expired certificate was still unrevoked at expiration time. Possibly, a CA may go out of business. And, as you note, involved cryptographic algorithms may also become deprecated.
The really important point is that when you want to verify a signature, you want to know whether the signature was valid at the time it was produced. Suppose, for instance, that somebody sent you a signed email (with S/MIME) on November 12th. Three weeks later (early December), the sender's computer is compromised and his key stolen; he dutifully contacts his CA, and the CA revokes his certificate. Does that mean that his signature ceases to be valid ? We certainly hope not !

When you sign, you really are building a legal weapon pointed at you. In the example above, if Bob sends you a signed email, then you want to keep it in order to sue Bob if he wants to default on his responsibilities described in the email. It would be too easy if Bob could escape your legal retaliation by simply losing his private key !

However, once Bob's certificate has been revoked, it can no longer be validated in the X.509 sense. What that implies is that S/MIME signature validation is transient. It works for some time, then ceases to work.

To really support long-term archival of signed object, you need to freeze things in time. The tool for that is a time stamp.

Suppose that Bob signs the email on November 12th, 2014. Two days later, you open your mailbox and you verify the signature; at that point, Bob's certificate is still valid and unrevoked, and you can obtain a set of CA certificates and CRL that demonstrate (within the X.509 model) that, on November 14th, Bob had really signed the email. Then you take the email, CA certificates and CRL, put all of these in a big bag (e.g. some archive format), and then obtain a time stamp from some time stamping authority. The time stamp is, basically, a short document containing both the time stamping date (November 14th) and the hash of the time stamped data (a hash of the Zip file containing the email, its signature, the extra CA certificate and CRL); and the time stamp is signed by the time stamping authority.

Then fast forward to December 11th. At that time, Bob's certificate is revoked, because he claimed to have been robbed of his private key on December 3rd. You want to revalidate the signature. To do that, you verify the signature on the time stamp; if it is correct, then it is a proof that the archive contents already existed "as is" on November 14th. So you can then validate the S/MIME signature, using the objects from the archive, as if the current date was still November 14th. At that date, no certificate was revoked, archived CRL were not expired, SHA-1 was still trustworthy, so everything is fine.

A time stamp is thus a time-travelling machine. The time stamp demonstrates that a set of objects existed at some date T; so it allows you to run any validation algorithm using these objects (and only them) as if the current date was T.

Now the problem becomes: how to organize that time stamping process ? In particular, the time stamp is itself a signature, that is verified at the current date (it is because the time stamp is valid now that you can then jump back to date T when using the archived objects). That signature, with standard time stamps, also uses X.509 certificates and is subject to the same kind of degradation. So what you really need is to chain time stamps: whenever the top time stamp is getting close to cessation of verifiability (typically the expiration date of the TSA certificate), freeze it with another time stamp. And so on.

Theoretically, there are standards for that. S/MIME relies on CMS, an extensible format for encrypted and signed objects. Among defined extensions for CMS are the CAdES attributes; when you get all of them, you have a CAdES-A object, which is basically the archive-with-chain-of-time-stamps that I was talking about.

(However, I strongly doubt that you will find any S/MIME-aware tool that also knows how to process CAdES attributes.)

The same concept is also applied for XML documents (and the XAdES standard), and for PDF (with PAdES). Recent versions of Adobe Acrobat support PAdES.


How does the Fake Authentication Attack from aircrack-ng work?

In fake authentication attacks, there are two types of WEP authentication (Open System and Shared Key) you can only do  fake authentication for WEP enabled AP. This useful when you need an associated MAC address in various aireplay-ng for example in WEP cracking attack when there is no associated client.
It should be noted that the fake authentication attack does NOT generate any ARP packets
How it works:

It sends an Authentication Request
It gets Authentication Reply, if successful it would send (3)
It gets an Association request
Association response it will make it successful

ARP-Replay attack is when an ARP packet is re-transmitted back to the access point. This, in turn, causes the access point to repeat the ARP packet with a new IV.
When this is complete and successful you can know do the Arp-replay attack so you can generate more ARP packets so that the IV can be revealed. This works because for an AP to answer to an ARP packet it has to have the MAC address of the wireless card that is doing that is replaying the captured ARP. That is why we do fake authentication.
To prevent this i only know of one way which is to stop using WEP and use WPA and WAP2. Because remember Fake authentication only works with WEP enabled AP.


How to pass an email address securely to a web application X embedded inside a web application Y

Depends on how the execution is.

If your sending the email as an plain text (none-encrypted) there are severe issues concerning integrity (Did the client-side change the email address?)
Assuming both domains are in your control this can be solved by encrypting the email address with your private key.


What's the secure way to write clear text password into a file?

Actually I found the answer right after writing the question:

https://stackoverflow.com/questions/11279335/bash-write-to-file-without-echo


Signal protocol implementations: pub key authentication and inspectability? (Allo, WhatsApp, FB messenger, Signal)

when Alice sets up a session with Bob, how can she be sure she receives his public key and nobody else's?

She currently can’t. (A better question would have been: how can Alice be sure that the client uses Bob’s public key for setting up the session, and not one of a malicious user?) The WhatsApp security whitepaper says:

For authentication, users can manually compare public key fingerprints through an outside channel.

There are two problems with this:

Alice has to rely on the client to generate the public key fingerprint / QR code. You may see the problem with relying on the client to verify that the client is using the correct keys.
Which brings us to the second problem: even if Alice can fingerprint the public key that the client stores for Bob without using the client, then how can she be sure that the client uses this key when she communicates with Bob, instead of e.g. using the public key of some malicious user? Verifying the protocol on the wire is what is needed here. The client being closed source doesn’t make things any easier either.

  can we check what happens on the wire?

Not as far as I know. In the Reddit thread relating to this question, one commenter notes that better documentation for the Signal Protocol will be published soon. Hopefully this will help. But what we really need for this are detailed instructions on verifying the traffic.

  to what extent do we need to trust the implementations, i.e. the service providers?

First of all, as far as I can see the Signal protocol includes basically everything that is required from an encryption protocol to set up secure e2e channels. If key exchange ever becomes secure, we have all ingredients needed for e2e communication.

But with the current implementations we’re not there yet.

So as an answer to this question, I’d say we should assume that the secrecy of our chat messages fully depends on the good will of the service providers.


Is browser memory cache considered as security issue?

It is really dificult to prevent a browser from caching anything at all. Even in private mode a browser uses caches, local databases and files on disk to speedup requests. All private mode does is promise it will be gone at the end of the session.

When you open developer tools and disable caching, it does not disable all caches either (AngularJS is known to cache problems).


How does HTTPS help websites under DoS attacks

The only reason switching to HTTPS might help is if the attack is focused on only HTTP. There is no inherent DOS protection in HTTPS. In contrary, you could probably tie up the resources of the server with HTTPS with even less efforts if you start with a minimal SSL handshake so that the server has something to do but never continue with the SSL handshake after the server has sent its response.


How can I understand this extract, concerning basic heap overflow?

There is an explanation in the actual book (maybe this 'leaksource' site isn't reliable ;-).

You type commands: mkdir /tmp/etc; ln -s /bin/bash /tmp/etc/passwd
(A)The heap contains two buffers and 104 bytes is the maximum distance between the first buffer and the datafile allocation buffer. (B)/tmp was not omitted, /etc/passwd will be appended to the end of the string shown in bold. The last part of that string shown in bold reads :/root:/tmp. So when completed with the above it will write …:/root:/tmp/etc/passwd to the first buffer and /etc/passwd will overrun into the buffer datafile @ 0x804a070 as shown on the next page. (C & D) It won’t write to /tmp/etc/passwd because that is only a symbolic link to /bin/bash.

The overall idea is to append the /etc/passwd file that has a User ID of 0 so you can be given root privileges. The way this exploit is carried out: “the overflow needing to be the destination file “/etc/passwd” doesn’t allow for us to append the file using myroot:XXq2wKiyI43A2:0:0:me:/root:/bin/bash (if we used this as part of the overflow it would write to /bin/bash). You are creating /tmp/etc/ for two reasons:

to have an overflow into the datafile allocation buffer of /etc/passwd (i.e. the file you want to write to).
to have a valid login shell for your entry into password file WITHOUT ruining the target system & actually messing up your whole password file.

A blog post that might help you out. If you aren't familiar with the linux commands like mkdir and ln, let me recommend CodeAcademy's Command Line Course or a command line tutorial out of many you could google.


What tools can recover or do forensic analysis on deleted registry entry?

That's Registry Explorer/RECmd from -- https://ericzimmerman.github.io/#!index.md


Ciphertext for email vs Ciphertext for database

If your original construction gives you the security properties you want, then simply replacing Alice_PU[KS] with Bob_PU[KS] should do the job.

Think of the database as a communication channel to your future self. Future Bob should still have his keypair, so can both decrypt the session key and verify the signature.


Why is Google still using a sha1 certificate on its own site when they are phasing them out in Chrome?

This may be a case of "do what I say, not what I do". Note that Chrome complains about use of SHA-1 for signing certificates whose validity extends beyond the end of year 2015. In this case, Google's certificate is short-lived (right now, the certificate they use was issued on June 3rd, 2015, and will expire on August 31st, 2015) and thus evades Chrome's vengeful anathema on SHA-1.

Using short-lived certificates is a good idea, because it allows for a lot of flexibility. For instance, Google can get away with using SHA-1 (despite Chrome's rigorous stance) because the algorithms used to guarantee the integrity of a certificate do not need to be robust beyond the certificate expiration; thus, they can use SHA-1 for certificates that live for three months as long as they believe that they will get at least a three-month prior notice when browsers decide that SHA-1 is definitely and definitively a tool of the Demon, to be shot on sight.

My guess as to why they still use SHA-1 is that they want to interoperate with some existing systems and browsers that do not support SHA-256 yet. Apart from pre-SP3 Windows XP systems (that should be taken off the Internet ASAP), one may expect that there still linger a number of existing firewalls and other intrusion detection systems that have trouble with SHA-256. By using a SHA-256-powered certificate, Google would incur the risk of making their site "broken" for some customers -- not by Google's fault, but customers are not always fair in their imprecations.

So Google's strategy would appear to be the following:

They configure Chrome to scream and wail when it sees a SHA-1 certificate that extends into 2016 or later.
Because of all the scary warnings, users of existing SSL servers (not Google's) begin to desert (e.g. they don't complete their online banking transactions, because they are afraid), forcing the server administrators to buy SHA-256 certificates.
Now these new certificates "break" these sites in the eyes of the poor people that must live with outdated browsers or firewalls. This ought to force people to upgrade these browsers and firewalls.
Meanwhile, Google's reputation is unscathed, because their site never trigger any warning or broke an old firewall -- since it still uses SHA-1 !
When the whole World has switched to SHA-256, and all firewalls have been updated, the path becomes clear for Google, and they can use SHA-256 for their new certificates.

It is a pretty smart (and somewhat evil) strategy, if they can pull it off (and, Google being Google, I believe they can).


Can an attacker gain any information from an application/octet stream if they have no access to the sending and receiving code?

Real-life data has a lot of structure which makes recognition easy. The Unix file utility has done so since 1973.

Not being able to figure out the ins and outs of a bunch of bytes means that the bytes are not distinguishable from random, unless you know a "secret convention" which governs the interpretation of said bytes -- this exists and is called encryption. Decades of research in cryptography have come to the following conclusion: encryption can exist, but it is not easy. If you do not apply encryption explicitly, then the meaning of the data is not secret but, at best, obscure. Experience shows that obscurity rarely lasts long.


What are the use cases for anonymous SSL cipher suites?

That TLS includes such capability is not without good reason.

It provides for confidentiality without the need for a certificate authority - an endpoint must be configured to remember what certificates it will accept, instead of which certificate authorities it will accept. This is a completely different trust model from that generally used on the internet, and should not be used on a public website.

I would not expect this cipher to be available in any browser.


802.11 deauthentication attacks can occur due to the way 802.11 frames are structured. The 802.11 spec controls not only the flow of packets between the client and the access point, but also carries other information such as frame type, power management, protocol version, and encryption schema used.wifi-planet .com understanding 802.11.

Deauth attacks by exploiting the 802.11 frame control for if a client is associated securely to the AP. The attacker send a series of "deauth" packets spoofing to be the unauthenticated client to the AP and checks to make sure the AP acknowledges that it received the packet. The attacker also send a series of packets to the client pretending to be the AP saying "hey you need to reauthenticate!". Then the client and the AP say "hey, We need to authenticate! you told me you're no longer authenticated! (this is due to the attacker's packets). Then the two reauthenticate, allowing the attacker to capture the complete handshake. Aireplay Documentation


The raspberry pi runs on the ARM1176JZF-S processor. ARM is used in more devices than just the Rpi. ARM exploitation is certainly possible. Have a look at the following papers:

A Short Guide on ARM Exploitation
Effective and efficient bufferoverflow protection
Return Oriented Programming for the ARM Architecture

Also have a look at this Defcon 18 presentation.

In regards to exploitation, Buffer overflows are definitely possible (refer to the papers for technical details).  On many new platforms the stacks are non-executable, thus attempting to exploit  them is more difficult than in the past. Techniques like ret2libc won't work because of the way ARM performs variable management. Variables are sometimes pushed across registers rather than being put on the stack, which makes it a lot more difficult to pop the right variables in order to jump to a piece of shellcode. Another type of attack can be used instead though as demonstrated in this paper which uses an adaption of the technique making use of Return Oriented Programming.

ASLR is primarily an Operating System responsibility. So it will largely depend on what OS you are running on your Rpi and if it was compiled with ASLR support. NX bits are implemented but can be circumvented using Return Oriented Programming.

Note that the ARM processor within the raspberry pi supports TrustZone which allows for two spaces:

Secure World
Normal World

ARM uses virtual cores to seperate these two worlds, which allow for different execution privileges (for instance  on Android this is used to seperate your mobile payment module to execute in a completely different zone than your normal applications). So even when you might be able to exploit your device, there is still a possibility that you will not gain access to sensitive data.

In regards to plausible attack vectors, it would depend on what you use the Rpi for. For other devices implementing ARM, attacks have been used to for instance unlock boot loaders (the exploit actually was able to bypass secure to normal world protections).


Displaying complete credit card information to end user

It sounds like you are saying that the web application masks the user's credit card, but that masking is only in the client-side UI; the server passes the full card back to the user at the API level.

I don't think this is technically a violation of the PCI DSS, because it is in fact masking displayed data, but it's clearly a violation of best practices and I would not be surprised if a QSA found it to be a violation.  Most stores are very careful never to "play back" the full PAN to a user, in case an attacker manages to get access to the account.


does filling phone memory overwrite all previous data

No, not necessarily. Flash memory uses wear levelling (changing the physical location of data stored) to maximize memory life. Most flash memory has some "spare" space that is unreported that allows it to replace bad parts as they wear out. This means that there may well be small amounts of (worn/bad) memory that still holds some of your data even after overwriting all memory reported by the phone. However the data on this memory would be arbitrary and I would expect it would require forensic tools to recover it.

I'm not sure on the eeprom/flash part


UAC is, in my opinion, too highly praised. True, it does protect against the more simplistic admin-requiring malware installation scenarios which were more prevalent before its advent, but it created new such scenarios, which are not much better.

In short, all that UAC changed is the following.

Before it came to be, malware authors could make malware that requires admin rights just hoping that their victims will be using an admin account.

After UAC was built into the newer Windows versions, malware authors switched to a better form of social engineering, disguising malware as legitimate software requiring admin rights. This kicked a few uncapable fools from the mal-market (good riddance), but the ones who remained and adapted their viruses to use this new attack scenario got a good chance to attack users who are not logged in as the administrator.

How? Well, UAC in non-admin mode allows you to enter the admin's password to start an app it's warning against. Moreover, it explicitly requires you to do so to start the app. From the point of view of user-psychology, clicking "Yes" and entering the password in a UAC prompt is way easier than choosing to run the program as an administrator in its standard settings.

Yes, you see, whatever the guys from Microsoft say, from the user-psychology point of view, UAC is a complete disaster. Just look at it: for example, most non-tech-savvy users with Java installed are bound to get the perfectly legitimate jucheck.exe screaming for admin rights to just check for updates every single day. Yikes. And that's just the tip of the iceberg. Many regular users get so used to UAC prompts popping up on their screen that they don't care about what the prompts say about the suspicious programs at all.

In short, if UAC annoys you, I'd recommend to disable it. It's just not worth the bother. Just make sure you're not often logged in with an admin account (like most Linux users do). It's basically the same as using UAC, but less annoying.


Volatility Plugins Directory Using Windows

As mentioned, this may be off topic, but I will go ahead and describe the solution I found. My issue was that the plugin I was using was corrupted. Nothing else was wrong. However, it is important with Volatility that when an external plugin directory is used, the --plugins option must be the first option specified after the executable or it will not work and no error indicating why will be given.


Two Phases of Secure Socket Tunneling Protocol (SSTP)

The first phase is to establish a secure session.  This is what the SSL session is for.  Once the SSL channel is established all data passed through it is encrypted.  The POP session is established through the SSL session.  Which means that all of its messages for establishing a PPP session are encrypted using the SSL encryption keys.

PPP allows for authenticating users.  So any user names, passwords, or other means of user  authentication is encrypted.   SSH does the same sort of process.  Establish a secure channel first, then allow for secure user authentication and data transfer.


How risky is using e-mail to manage passwords?

... I make sure that all copies are removed from the server.

No, you don't. Copies may exist in backups, swapfiles, wear-leveled Flash memory, and elsewhere.

  If a hacker did happen to gain access, he would not likely think to look ...

Now he would.

Just use one of the well-reviewed password manager programs. Re-inventing the square wheel is a poor use of your time.


What are the consequences of revoking OpenPGP subkeys and generating new ones?

What happens to my existing public key? Do I need to export my public key again, and have it signed by trusted partners again?

By revoking the subkeys but not the primary key, you do not have to collect new certifications (each certification points to a pair of a user ID and primary key, subkeys are not relevant with respect to certificatoins).

As you revoked the subkeys and generated new ones, you should distribute a new copy of your public key (which in this case is considered a collection of primary key and subkeys (including the revocation certificates for the old subkeys), user IDs, certifications, ... Your actual public primary key is not updated during this process, though.

  Can messages signed by the new signing subkey, be validated by the public key I already distributed in the past?

No, others have to fetch a new copy of your keys. They do not need to validate your primary key again, though.


Non SSL website with external SSL secured service

It is a security concern, because half of transport between end user and end application is unencrypted and will be a subject for MITM. That is, SSL between your app and end app doesn't make much sense, because transport between user and your app is wide open for any kind of manipulations. You really should protect all communication transport with SSL certificate.


Error on Content Security Policy while testing for Clickjacking

This warning just means that a script was already explicitly trusted by nonce-source or hash-source and that the additional unsafe-inline makes no sense in this context - and thus will be ignored. The warning does not indicate that any bypass could be possible.