How to access or scan a specific computer in a different network

Your neighbour  router is acting as a firewall¹

This is actually a side effect of NAT: the router is blocking the connections from the outside to the intranet.² In order to interact with a computer in the intranet from the outside,³ the appropriate port needs to have been open in the router to that computer. And you will only be able to interact through that port.⁴

Given your description, the internal network is not accessible from the outside, so there's no forwarding of packets from the internet onto it.

Thus, the only way to scan a computer in the internal network would be to jump into a host directly connected to the internal. This could be either the router itself or any computer on the intranet that is accessible from the external network. And it could both be an unintended access (like exploiting a vulnerability on one of those computers) or an allowed one (like publishing a ssh server or VPN endpoint).

¹ Albeit a very basic one
² There are loads of vulnerable systems not exploitable because of this. If the network is changed to implement IPv6, they may become exposed though.
³ I am exclusively taking into account remote-initiated connections, not eg. the interaction with an internal browser of the requested web server. Nonetheless, having an internal user to connect to you (be that opening a website that runs a browser exploits to directly tricking the user to run a remote shell) is a potential concern.
⁴ There are some cases where more ports may be dynamically opened, like with routers that inspect FTP.


You can dynamically add the CSRF token to forms via JavaScript. But you need to be aware of a couple of issues:

If you have cross domain forms you need to be careful that your JavaScript code doesn't add CSRF tokens to them, as it would leak the token.
If your application requires users without the highest level of privilege to create forms, then they can perform CSRF attacks as tokens will automatically be added.
HTML injection will lead to CSRF via injection of a form, which increases the impact of HTML injection a bit. In the same manner, if you allow a subset of HTML for some users, and your filter has a vulnerability that allows creation of forms, you will be vulnerable to CSRF.

Unrelated: CSRF tokens always need to be in two places; the most common approach is storing them server-side in the session and additionally in another place (eg submitting them in a form). That seems to be what you are referring to in your question. With this approach, storing the token in a cookie instead of a form will not work (it will always be submitted and will validate against the server-side token). Storing the token in a cookie would be used in place of storing it server-side. You still need to submit it eg via the form.


There is no way to detect if DKIM is implemented by the sender without getting a mail from the sender, extracting the selector from the DKIM-Signature header and getting the DKIM policy from DNS based on this selector.

One can check if some commonly used selectors can be found in DNS. But a successful check does not mean that any of these selector actually gets used for signing nor does it mean that the messages gets signed at all. And, no typical selector found does not mean that DKIM is not implemented.


Is it safer to be setup as a user with 'standard' vs 'administrative' privileges in Windows 10?

Simple answer, yes he is safer but not "safe". If an attacker who has delivered a payload to the machine whether from an iframe or a redirect, the machine is owned and there is little to nothing you can do about it. The problem is not that it would help with some attacks, but it would make little difference in a vast majority of them.

I would say on an at-home computer that I don't use for work purposes at all, that having a separate admin account is over the line of usability vs security in my mind. I reinstall from an image of what I consider "needed" software at home a few times a year and I keep no personal information on it. I do however, have a "work" laptop that has a separate admin user/pass that does have information I want to keep out of the hands of miscreants and I do take much greater care of security measures on that machine.

The questions, as always, is security vs usability. Is banking done on the PC? Social Security #'s? Company info? etc... Once those questions are answered you can arrive at the best answer for the situation.


Identification through digital signature. How safe is it?

Digital signatures are used extensively for authentication in many secure protocols, such as SSL/TLS, SSH, etc.  Of course, this requires the verifiying party to have some way of knowing that the public key purported to belong to the autheticating party is true and correct.
The parts that are not clear from the description of your process are:  1) How does Bob authenticate you?, and 2) How is the data transferred from you to Bob securely?
Ideally, your protocol should have a way for the client and the server to mutually authenticate each other, and for the data be encrypted as it is sent through the network.  It's best if the encryption is done using perfect forward secrecy (PFS), so that if an eavesdropper on the network records the cyphertext passing through, he can not later decrypt the cyphertext even if one of the parties' private keys is later compromised.
For the sake of this question, assume that each party has a long-term key pair, and each party has some way of knowing that the public key purported to belong to the other party is true and correct.  Modern protocols (such as those mentioned above) accomplish all of the above using a method along the lines of the following:

Client generates an ephemeral key pair and sends ephemeral public key to server.
Server generates an ephemeral key pair and computes shared secret using server's ephemeral private key and client's ephemeral public key.  Server signs shared secret using server's long-term private key, and sends ephemeral public key and signature to client.
Client computes shared secret using client's ephemeral private key and server's ephemeral public key.  Client verifies server's signature on shared secret using server's long-term public key.  Client signs shared secret using client's long-term private key, and sends signature to server.
Server verifies client's signature on shared secret using client's long-term public key.

At this point, if all of the signatures have verified, the client has authenticated the server, the server has authenticated the client, and the client and server share a shared secret.  This shared secret can be used as an encryption key to a symmetric encryption algorithm (such as AES), so that the two parties can share information between each other securely.  At the end of the session, both parties discard the shared secret and the ephemeral keys to ensure PFS.


XSS alert not working with concatenated string

You have to remove space in ": " or add quotes for onerror attribute value:

<img src=0 onerror='alert(document.domain+": "+Date.now())'>


If u cant send the link, that would be a case of self-xss which involves the victim injecting malicious javascript snippets himself, which is a non-vulnerability in the bug bounties i have come across or even for professional assessments. However, social engineering attacks have been reported in the past wherein an attacker convinces someone to paste malicious javascript promising some result but in actual it ends up causing harm to the victim. Since, this involves a lot of user interaction, it is mostly a non-vulnerability. But, adequate protection should be put in place so the input isn't reflected anyways.

More about self-xss at :
http://en.wikipedia.org/wiki/Self-XSS


How useful is CISSP to a recent graduate?

The CISSP certification is intended to demonstrate two things:

Knowledge of the material in the ISC2 CBK, and
Significant real-world experience in the field

To an employer, a CISSP on a resume is supposed to mean that the application knows what s/he is doing and has demonstrated it with years of experience.

Note that an employer looking for a CISSP for an entry-level position does not know what they are doing.  It's like requiring 10 years experience with Ruby on Rails, which has only been around for 7.  Also, requiring a senior-level cert for an entry-level job probably means the compensation won't match the job's responsibilities.

While you could take the exam now and become an Associate of ISC2, that doesn't buy you much.  An alternative could be to take the less rigorous SSCP exam, which only requires one year professional experience, or the Security+ exam which is a good starting point with essentially no prerequisites.


What's the point in a proxy server authorizing/authenticating clients?

This is really two questions, but eh...
What's the point of proxy authentication?
Contrary to what you seem to believe, there are many reasons beyond anonymity to use a proxy (and if you want good anonymity, you should use something like Tor rather than a single proxy). A few of those reasons:

Bypassing geographical or IP-based restrictions.
Using the proxy as a bridge between the network you're on and one you want to access (for example, getting from an internal corporate or cloud network out to the Internet, or the reverse).
Using a proxy for monitoring, logging, or filtering network traffic (for your own security, or for the security/control of a company or other entity that wants to limit what you can access on/from its network).
Using a proxy for intercepting or modifying network traffic (for security testing, or for tampering with network traffic).

For many of these purposes, there are good reasons to use authentication. For example, a geo-filtering bypass proxy may be offered as a commercial service, and they want to ensure that only paying users can access the proxies they provide. A corporate proxy wants to ensure that only authorized employees are able to access its network, and possibly also to know which employee is using a particular machine for monitoring and logging purposes. Somebody using a network testing proxy that is opened to other devices on the network may want to make sure that only their own authorized devices can connect to the proxy, rather than allowing arbitrary network users to connect and send requests either directly to the proxy or from their computer.
Additionally, having an open proxy is just risky. For example, suppose somebody used an open proxy that you run to send death threats or upload child porn or something else illegal like that, and it gets traced back to your IP address. That's not a good situation to be in (though I'm not a lawyer and am not sure exactly how much legal jeopardy you might be in there), especially if you don't have any way to demonstrate it was somebody else (such as a proxy's authentication logs).

Shouldn't encryption, if used, be end-to-end?
In general, yes, but that's not always practical and there might be reasons to want to separately encrypt the client-proxy traffic anyway. There's no reason that you can't run end-to-end encrypted traffic, such as HTTPS, through a proxy where your encryption to the proxy is itself encrypted. In fact, if you were using the proxy to conceal your network activity from your ISP or similar, you would absolutely want to do this (otherwise the ISP would be able to see your DNS lookups, the domain names of the sites you wanted to connect to, the amount of network traffic you exchange in each direction with each site and at what times, and so on). Encrypting the connection to the proxy is also obviously helpful any time you want secure authentication, although there are ways to do reasonably-secure authentication over insecure connections (such as SRP).
Also, encrypting the connection only between you (the client) and the proxy is still better than no encryption at all, which would be the case when connecting to a server that doesn't support encryption (such as one that only supports HTTP or FTP, for example). A local network attacker still can't see (or modify) what you're doing (as they could if the proxy connection was unencrypted), even though the proxy server and anybody downstream of it can.


Still a threat? Of course! It's one of the most exploited vulnerabilities out there! Just take a look on the SQL Injection Wall of Shame and see for yourself.

I don't think SQL Injection will ever become extinct. It arises from the fact that humans are writing programs, and humans are not perfect. And as long as we write code, with the deadline arriving at the horizon, we commit mistakes, and let open the door for SQL Injection.


Overall GET is something you would avoid to send query parameters, POST is the way to go.

If you would like to encrypt the messages inside the POST, for they can also easily be logged the same way GET requests are, I would suggest using something like JWE (Json Web Encryption). This is basically a JSON payload encrypted inside a JWT (Json Web Token)
https://tools.ietf.org/html/rfc7516


Is it secure to have only https binding in IIS?

It is not possible to "trick" the server, but there are a couple of caveats here.

First, it is still possible to set up another site in IIS with a binding that will accept HTTP requests, so you need to be aware of the configuration of any other sites hosted on this server.

Second, this configuration means that if people attempt to visit the site directly or otherwise over the HTTP protocol, they'll simply get an error.  Depending on your use case, this may be fine, and it's certainly the least complex option.  If you have people accessing the site via a browser however, it's probably not. If it isn't you can (as you already know) set up an HTTP binding and redirect.  This has the added advantage of preventing other sites from binding HTTP to this IP/host name, reducing the likelihood that a second site will erroneously serve the site over HTTP.


The security update for Apple does not disable SSLv3, but it disables "cipher block chaining", which is at the heart of the POODLE exploit, explained by CISCO:

  "The vulnerability is due to improper block cipher padding implemented in TLSv1 when using Cipher Block Chaining (CBC) mode. An attacker could exploit the vulnerability to perform an "oracle padding" side channel attack on the cryptographic message. "

So the POODLE testers are looking for SSLv3, which is one way to mitigate POODLE, but disabling CBC mode is also a great way to protect yourself.

To answer the heart of your question, no, you do not have control over the cipher suites used in Safari. But the APPLE-SA did fix the POODLE vulnerability.


How can the Same Origin Policy protect the user in times of CORS headers?

CORS is a way to deliberately and controllably punch holes in a site's own protections, specifically in the protections provided by the same-origin policy (SOP). You can only abuse CORS to attack another site if the other site has lowered its defenses too far.

I'm going to lay out some scenarios that may help you understand. Assume, for these scenarios, that there are adequate protections against CSRF and no XSS vectors or other conventional cross-site attacks possible.

Site V is a valuable target. That is, it's a web application that users sign into, and it holds access to valuable data or is otherwise something people would like to compromise the users of.

Site P is a trustworthy partner of site V. It needs access to some data from the user's session on V, but it is run by a party that V's owners trust.

Site M is a malicious website. Its purpose is to lure users who are currently signed into site V, and try to compromise their sessions.

User U is currently logged into site V, but also visiting site M. They are using a typical web browser, which supports SOP but also CORS.

Scenario 1: No CORS in use. Site M can make U's browser send all the requests it wants to site V (although non-simple requests get no further than the CORS preflight), but site V doesn't send back and CORS headers. Because of the SOP, the browser drops the responses to these requests, and M can't see anything. On the other hand, site P can't either.

Scenario 2: Overly permissive CORS. Site V's administrator has foolishly set up their site to return Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: <X> for any Origin: <X> in an incoming request. In other words, site V allows authenticated CORS requests from any origin. This allows site P to retrieve data from V, but it also allows every other site to do so as well; in effect, site V has turned off the protections it would normally get from SOP. Site M causes U's browser to send authenticated CORS requests to V, V responds including the CORS ACAO and ACAC headers mentioned above, and site M steals all of U's data out of V.

Scenario 3: Securely-configured CORS. Site V's administrator wants site P to be able to see data from site V, but no other site. Thus, incoming requests specifying Origin: P receive CORS headers that allow access (Access-Control-Allow-Origin: P and Access-Control-Allow-Credentials: true), and site P is allowed to make CORS requests to V and retrieve data. However, requests originating from all other sites receive no CORS headers in response at all, or perhaps just always receive Access-Control-Allow-Origin: P which doesn't do the request-initiating sites any good because they aren't site P. Thus, site M's attempt to read data out of V is again blocked by SOP.


How can I practice using nmap without scanning some real site or performing computer trespass?

There is a specific URL for that : scanme.nmap.org

  Hello, and welcome to Scanme.Nmap.Org, a service provided by the Nmap
  Security Scanner Project and Insecure.Org.

  We set up this machine to help folks learn about Nmap and also to test
  and make sure that their Nmap installation (or Internet connection) is
  working properly. You are authorized to scan this machine with Nmap or
  other port scanners. Try not to hammer on the server too hard. A few
  scans in a day is fine, but dont scan 100 times a day or use this site
  to test your ssh brute-force password cracking tool.

  Thanks
  -Fyodor

If you are looking for vulnerable webapp here are some good lists :

Hacking Vulnerable Web Applications Without Going To Jail
Deliberately Insecure Web Applications For Learning Web App Security


Does PCI actually require card informations to be encrypted in memory?

TL;DR

Technically, PCI requires card holder data (CHD) to be encrypted both in transit and at rest. This may seem simple at first, but the reality is, it doesn't get very specific about delineating between rest on disk vs. volatile memory. If you want to be pedantic, volatile memory is still data at rest, but according to the FAQs, it's not explicitly required to be encrypted while in memory. Though it's good to point out that this is just the FAQs, not actually in the PCI DSS Standard itself. Here's a good article to read for more info.

Long Answer

The reason for in-memory encryption has to do with the memory-scraping attack vector.

  PCI DSS does a good job of making sure credit card data in persistent
  storage is secure, however, such data in non-persistent storage --
  such as files stored temporarily in memory -- can still be vulnerable
  to compromise, particularly via memory-scraping malware. Learn more
  about this threat. SOURCE

More info about what PCI requires can be found here. The TL;DR of the long answer is that if you do not encrypt the data at rest (on disk or in memory), make sure you have compensating controls to mitigate the risk of data loss.

  If stored cardholder data cannot be encrypted, consult PCI DSS
  Appendix B: Compensating Controls and Appendix C: Compensating
  Controls Worksheet.


How can I sign a file with an alternate key

You specify a different default secret key. See section 1.2.1 of the GnuPG documentation.

gpg --default-key 28FDD919 --sign example

You can also change the default key in the GPG configuration file to make it persistent.

default-key 28FDD919

As a side-note, RSA 1024 is obsolete now days and is weak. 2048 is the recommended minimum.


Security and privacy concerns about "IMEI check" websites

I tried to enter my IMEI and I got some accurate information like model, specs, warranty, purchase date, carrier, etc.. They are obviously not an authorized body. Or are they?

The GSM/3GPP standards specify the purpose of the IMEI as identifying the mobile equipment (the device, not the person using it). These are industry standards.

I did some research online and on academic papers and IMEI does pose a minor risk in privacy and spoofing by counterfeiters. I am asking is disclosing millions of IMEI numbers to such websites has any serious risks? Am I vulnerable after I used it?

To properly answer whether you are "vulnerable" would require more context. But I suspect the answer is "no, you are not."
Remember, the purpose of the IMEI is to uniquely identify the device--the actual physical electrical/radio equipment used to connect to the tower/network--not the person using it.
The SIM card is used to identify the mobile subscriber (e.g., person with billing information). You can use different SIM cards with the same device (same IMEI).


Do sudo and .profile/.bashrc enable trivial privilege escalation?

Anything you can do on a compromised account, an attacker can do as well.

Fundamentally, this is because Linux providers isolation between users, not between individual processes running as the same user. Any process running as a given user is considered to have equivalent capabilities as any other processes running under that user.

  Is it true that the system sudo executable can be circumvented in this way?

Yes, and in other ways as well. If you elevate privileges to root on a compromised unprivileged account, you compromise root. If you drop privileges from root using su to an unprivileged account, you also compromise root! You can never safely elevate privileges on an untrusted account. While it's possible to exploit the system using PATH, it's also possible to hijack the bash process itself to sniff key input. Disabling execution with noexec is further not useful because interpreters (bash, python, perl, etc) will still run. The noexec option is not and has never been designed as a security feature, despite it being regularly peddled as such.

An incomplete list of ways an attacker could hijack the use of sudo or su:

Using the LD_PRELOAD variable on the parent process (e.g. bash).
Hooking the parent process with ptrace() or process_vm_writev().
Sniffing or injecting keystrokes into the terminal emulator using the X11 protocol.
Creating aliases or functions to wrap the actual sudo executable.

I explained these in more detail on my answer to another question.

  Why are desktop Linux systems, by default, set up in such an easily exploitable way?

Elevating privileges on an untrusted account is not something you are supposed to do. Not to mention, desktop Linux is an afterthought in the grand scheme of the general *nix architecture. It is a failure of security theater incessantly repeating the same bad advice, not a failure of the security architecture of Linux itself. People repeatedly say to use sudo for root because many new users will instead run everything as root, even their browsers! In this case, it is better to be using sudo. It is harmful in the case where the user is already smart enough not to use root for everything.

Note that sudo is highly configurable and can be designed to allow only certain commands. This is where it really shines. You can configure sudo to only allow you to run apt-get update as root (with or without a password), and deny everything else. That would additionally restrict an attacker from doing anything other than... well... doing a software update.

It's important to remember that, even if you configure it to only allow running certain commands as root, you can still shoot yourself in the foot if you whitelist programs that are not designed to run as root via an untrusted user. I saw a real-life example of someone trying to run VeraCrypt in this way and explained why it is insecure. The idea was that VeraCrypt is safe to run as root, so it should be safe to use sudo to elevate it to root as an untrusted, unprivileged user. It turns out the idea is flawed, and allows trivial privilege escalation!

  Shouldn’t the default way to invoke sudo make sure that it is, in fact, the executable provided by the system (nobody is going to type /usr/bin/sudo every time)?

Typing the full path will not protect you! You can easily create a function that contains a leading /, and it will override the real executable. Even if the executable did make sure that it is genuine and attempted to defeat sniffing, a malicious process could hijack the bash process and sniff keystrokes independently of sudo, making it impossible to detect from its point of view.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

  In such an environment, it seems that using sudo is fundamentally insecure and one would be better off enabling login as root and logging in on a separate TTY.

This is always the case. Note that even logging into another TTY is not perfectly safe. You should use SAK, the Secure Attention Key combination, to ensure that you are interacting with a genuine login session (agetty or logind, for example). SAK is a key combination that the kernel listens for (and thus cannot be repressed by userspace). When it detects it, it will kill every process in the current TTY, triggering the login prompt to appear. If you have switched to a genuine, uncompromised TTY, then it will only cause the prompt to disappear and reappear. If you are on a hijacked TTY, it will kill the malicious process and bring back the genuine login prompt.


Drawbacks of using ADFS for SSO for external users

The only reasons to create a separate AD domain is to have a different password policy, to segment replication.

You can minimize risk of a compromised DC only by having a new forest.  Any domain in a forest can result in compromised Enterprise Admin credentials.

The ADFS server must be trusted by both domains, so a Domain trust or a forest trust is needed.  If you don't do this, then home realm discovery will become difficult.

If you intend to use MSFT online, Azure AD for synchronization, multiple domains and forests are supported but it's more complicated.  Just know that when you provision in one location (US) it doesn't allow you to share the same namespace in the UK.  (e.g. user@domain.com is country specific).  This is a temporary limitation that will be corrected soon.

ADFS vs Ping vs Auth0?  Well who are you integrating with?  What are your in-house skills?   do those providers have the PII protections you require?

Yes, AD can scale to over a million of objects (the US Army/Navy has a massive AD forest). This info is from 2007 so I'm sure it's much higher now.

Question for you - what do you have resources for: one perfectly robust AD infrastructure, or two infrastructures?  (e.g. isolate the outages/load)


Is storing passwords associated with system processes and binaries in an encoded format acceptable?

It's seems acceptable as long as you realize what the risks are and what the alternatives are. In the encoding case, anybody that can access the encoded password and knows how to decode, can get hold of the password and accesses the protected resources.

I wonder though, if a system knows how decode an encoded password, the system should also be able to decrypt a stored password using a master key. And that alternative is discussed in the reference link.The question in that case is how difficult is it for a third party to 'find' that master key.

I have a similar case, an automatic incremental backup that requires an encryption key. That key itself is stored, but encrypted by a kind of master key on my PC. The master key is stored somewhere and could be found or is reproducible though, if one knows how to.

I'd say that both cases classify as security by obscurity, which is bad if there are alternatives availabe. I'd prefer the backup case that perhaps offers more obscurity options. In the end, in both cases a secret is accessible for third parties.


solaris equivalent of /proc/self/environ LFI

On Solaris, you get a process environment with these commands:

pargs $$
pargs -e $$

There is no shortcut like /proc/self with Solaris so you need to know the PID of the process, eg.:

/proc/$$/psinfo

Moreover, only the arguments are visible here, the environment is in /proc/pid/as and I doubt this file to be exploitable with LFI as it is kind of a sparse file with which you need to seek to precise locations for the read to succeed.


Has anyone used a file hash to prove authenticity of a file during legal proceedings?

Yes, it's a routine step in Computer Forensics.  But you really should read Law Is Not A Science: Admissibility of Computer Evidence and MD5 Hashes by Rob Lee.  In short, don't expect waving a hash in court to prove anything - you need to present the story of the hash in a way that the court is comfortable trusting it.

If you're implementing a solution, think not in terms of the technology but in terms of what the court would need to know.  That means logging the introduction of the file into your system, and then being able to prove tie a later-in-time copy of the file back to that original provenance.  The hash is how you prove they are the same.  Make sure the proper logging is in place to show who (user ID, IP address) uploaded the file (hash) when.

If "when" is important to your legal concerns, you should look into a Trusted Timestamping service - you provide the log entry with hash, someone timestamps and signs it, you can later get that verified to show that yes, really, you had hash adef01....42fc in hand on 7 June 2018.


This condition was probably not an exploitable XSS vulnerability for most applications.  This is more likely a "defense in depth" filter to prevent programmers from unintentionally causing problems.

XSS is solved in an API's by setting the content-type to application/xml or application/json depending on the return data type (and text/plain is also commonly used to prevent XSS). Reflective and Persistent XSS can only be a problem if the page has an HTML content type.  DOM based XSS is still a concern for web services.  The Content-Security Policy can be used to further restrict the ability to execute JavaScript using HTML injection,  and is useful in preventing DOM-based XSS.

When using a modern browser, an XSS payload shouldn't execute on a non-executablite content type.  Never the less, it is a good idea to explicitly disable content sniffing for legacy or non-standard browsers:

X-Content-Type-Options: nosniff


Should I use Google Accounts or my own hashed password system?

Google offers 2 factor authentication, but because the account can be used for many sites there can be more likelihood of someone gaining access to an already authenticated client. As you are trusting google anyway (with Google App Engine) its not much more attack surface to have them manage authentication as well. Hosting on your own server with 2 factor authentication and Public keys would be the most secure option if you have the time and know how.


Is some kind of CSRF possible using img/script tag to read sensitive information

With just an image tag - no.  For the attacker to be able to gather data from the API endpoint and return it to himself, he would have to have javascript on the page under his control.  With javascript/ajax requests the browser will still pass along cookies and therefore authenticate his request, potentially allowing him to receive a response and then send it off to a new server.

However, any attempts to do this will run afoul of the same origin policy in the browser.  This states that if a script requests a document from a site with a different host, port, or protocol, the response will be denied from the script unless it is explicitly approved by the destination site.
 The most common way to approve cross-domain requests is via CORS.  As a result, the only way an attacker would be able to actually read the response from your endpoint and retrieve the data is if you (the domain owner) have explicitly told CORS to allow credentials and also white-listed the domain name that the malicious javascript is running on.

To get around that restriction the attacker would have to get their own javascript to run on your domain, but at that point in time we're talking about an XSS attack, and you're pretty much hosed.  There are ways to prevent data from getting back to an attacker even in the event of a successful XSS attack using well configured CSP headers, but CSP headers can be tricky to get right and they don't yet have broad browser support (in particular IE).

The closest analog to what you are talking about is XSSI/JSON hijacking.  These are different techniques to bypass same-origin-policy restrictions in the browser:

http://www.thespanner.co.uk/2011/05/30/json-hijacking/

However, the techniques that allow these restrictions to be circumvented have largely been patched in modern browsers, making the vulnerability much less relevant:

https://stackoverflow.com/q/16289894/1921979

It is always possible that additional such weaknesses can be found in the future, in which case there are some techniques to protect against XSSI (h/t Xavier59):

https://security.stackexchange.com/a/110552/110133


Internet security - how long does the NSA store data?

According to General Alexander when he started the digging for the Utah facility, he said the goal was to "capture as much as we can, and keep it as long as we can"

In other articles, I have seen discussion that they are especially interested in keeping encrypted communications longer, so if one day they get the key they will have the whole history of communications of a specific target.  And you can bet they or the FBI keep a special eye on Tor communications.

They do utilize minimization, so they don't have to store irrelevant information.  So your letters to grandma are probably not stored very long at all.

Now, keep in mind that as of the latest legislative move, it is the phone companies themselves that store most of it.  It hasn't been made clear exactly what the NSA stores, other than that they have said they will request information from the phone companies for specific targets at specific times, following legal procedures involving the special Foreign Surveillance court.

Sure, information security is a thing.  But mostly it is not the NSA you want to worry about.

The big worry is the idiots like those kids that sniffed credit card numbers from a large store from their car in the parking lot.  Or someone sniffing packets at an airport.  Or at a McDonalds.

You definitely want to use HTTPS-Everywhere in Chrome, at the very least.  Or maybe a VPN service like Tunnelbear.  Just enough security to keep the casual script kiddies from getting into your business.


How is SAML solving the cross domain single sign-on problem?

It actually can be a cookie, because it needn't be associated with the service provider at all, only the identity provider.   All either of the two service providers are going to do is make the authentication request to the identity provider, so the process for an unauthenticated user is going to be the same for sp.example1.com as it is for sp.example2.com.

However, when the first request is made from sp.example1.com and the user is redirected to sso.example3.com, the user will login to sso.example3.com and can then set a cookie for sso.example3.com.

Then, when the user visits sp.example2.com, it too will redirect the unauthenticated user to sso.example3.com, but this time, the browser will have a cookie to send along with the request from the last time the user visited sso.example3.com, even though that visit was initiated by a different service provider.

Thus, the cookie from sso.example3.com can identify the user as already authenticated, and the identity provider can continue the process of issuing an assertion for the user to sp.example2.com without requiring the user to complete the login workflow again.


Biometrics for screen locks vs encryption

Can a file be symmetrically encrypted using something like a fingerprint? If not, does it just have to do with a lack of available data points, or is there some other explanation?

You could scan a fingerprint, and use that file as a key. It's a terrible idea however. A fingerprint is relatively easy to obtain, and nearly impossible to change. A brute force attack on this type of key is probably quite effective too.

  Could something like multi-factor authentication exist for symmetrical encryption, such as requiring data from both a password and fingerprint?

Two-factor authentication relies on two things. One is something you know (the password), the other is something you have or something you are (in pratice, that means biometric data). In a sense, this would make a second part of the key.

Biometric data, due to the fact that it can't be changed, is a poor part of a key.

Something you have could work - the recipient of the encrypted message could be given a black box that contains part of the key. Or you could use a device that uses a challenge-response protocol.
The difficulty is that the recipient must be given this black box ahead of time. If the amount of data you want to communicate is limited, you might be better off giving them a one-time pad.
But it is an option - I know of at least one bank that issues a device that, when presented with the bank pass and proper PIN code, allows the user to get in a challenge-response protocol to prove their identity for a transaction. A similar mechanism could be used for releasing part of a symmetric encryption key.
Whether or not that is efficient is an open question, as that part of the key itself would need to be communicated via a secure channel.


Spoofing the identity of another user in Telegram

Yes.

Every Telegram account has a phone number attached. You can see the attached phone number to check if is the correct one.

If you don't know the phone number of someone, anything can be shown as the avatar and name. Whether or not you trust someone just based on this, without knowing the phone number, is up to you.

The same with an alias. Every account has an alias (@nickname which is different from the name shown). If you know the real one, you can check it. If not, you don't know if is the real person.


iPhone 5c iOS 7.1 deleted video recovery?

Recovery is possible if the page-files containing the video have not yet been overwritten. I would advise you to act fast as SSD drives are more prone to permanent data loss compared to classic HDD drives. To make things more difficult, different SSD drives use different approaches for writing/updating data sectors so even if you have extra space, installing a new app or storing extra data could overwrite the page-files which contained the video. Another problem is that SSD drives use voltage to set 1/0 bits and depending on the quality of the drive and the up-keeping mechanism, deleted data sectors could degrade (permanent loss) over-time hence you should act quickly.


Does SSL inspection break applications utilizing certificate pinning?

Does this mean that these applications cease to function completely on
  corporate and academic networks that utilize SSL inspection, unless
  the administrator specifically exempts them

Yes,You are right the apps that use certificate pinning wont work in an MITM situation.They didnt work when i tried so i think its a fair assumption to make that they wont work in corporate and academic networks that utilize SSL inspection
unless the administrator specifically exempts that traffic and doesnt try to MITM it.


What is currently the best Searchable Encryption (SE) algorithm that works in practice?

I was at this talk earlier this year and was impressed by the approach. The product is called EncryptedQuery which attempts to solve the (I assume related) problem of Private Information Retrieval. PIR is probably a stronger requirement than SE since with PIR, even the db server isn't allowed to know what you searched for or which record was returned.

My notes on the talk:

Motivation: cases where you want to keep your data access patterns private.
PIR is intertwined with the problems of Oblivious Transfer and Secure Multiparty Computation.
In 2016 NSA open-sourced a PIR software stack called PIRK
In 2017 PIRK project retired. The company Envieta took up the project and renamed it EncryptedQuery
It uses Paillier encryption, which is homomorphic in the sense that addition in plaintext space becomes multiplication in ciphertext space.

My understanding of the algorithm (probably wrong, though this made sense at the time) is that the requester encrypts a string

encr_req = encr(0 0 0 0 0 1 0 0 0 0 ...}

where say the kth column containing the 1 is the row number that it wants retrieved. Once this string is encrypted, the server doesn't know which column contains the 1.

Then the server iterates over the database doing

sum_i( encr_req[i] * encr(data[i]) )

Because Paillier is homomorphic and all but one of the plaintext values is 0, this is equivalent to

0*data[0] + 0*data[1] + ... + 1*data[k] + 0*data[k+1] + ...

So when you decrypt, you'll have your result.

decr( sum_i( encr_req[i] * encr(data[i]) ) ) = data[k]

Pros:

The server is able to handle retrieving items from the database by ID without knowing which ID was requested.
Bandwidth of the response is low: sum_i( encr_req[i] * encr(data[i]) ) is the width of a single database field.
Can be extended to request multiple items in the same query.

Cons:

Performance: for each request, the server needs to iterate over the entire database, encrypting every entry with the requester's public key.
All rows in the database must have the same bit-width (which you want to keep small for performance reasons on the encryption step).
Number of entries in the database, and their order, must be fixed and known to the requester.
For large or less structured DBs, use a more general (but less secure) Searchable Encryption.

TL;DR I'm not sure this actually answers HelloWorld's question about what's the best searchable encryption :/


Postfix SMTP - Can I use SSH public keys instead of sasl password

Postfix ... Can I use SSH public keys instead of SASL password?

In short, no.  Postfix uses SASL, and while SASL supports a variety of different authentication mechanisms, SSH pubkeys is not one of them.

That being said, SASL does support a number of sophisticated mechanisms that would serve your purpose of making login non-trivial for attackers to attempt.  The biggest problem may be finding and configuring a complex mechanism that is supported by your legitimate clients!

The simplest way to incorporate public key authentication into your Postfix SMTP workflow is to use the Postfix SMTP TLS settings to require authentication, as described in this documentation.

Alternately, as this answer outlines, you can force your legitimate clients to connect via SSH and connect to the SMTP server over an SSH tunnel, thus meeting the same goal.

  Is it possible to completely change the login authentication such that
  a public key must be used instead of password so that these automated
  bots require more advanced methods to even hit the smtp server in the
  first place?

Some of the SASL mechanisms listed on the page above are, effectively, public keys - for example, RFC 3163 (but note their caveat about it being less useful than simple TLS).

The lack of pubkey SASL mechanisms is likely due to the fact that everyone considering one looked at the alternative of doing the same thing at the TLS layer and said "Solved, no need to work on this!"

  For websites that are on a server also acting as a mailserver, is
  there a method to only allow authentication from vhosts on this
  webserver itself?

Certainly, if they're on the same machine, you can set up an SMTP listener on localhost (127.0.0.1) which your web server process can connect to but which is unavailable to outsiders.  You could also trust relay without authentication on that server, since it's not accessible to others.  Look at the Postfix master.cf file for setting up different or additional listeners.


No.  ASLR is an important part of kernel security.  Non-root users are not supposed to be able to turn off ASLR.  The only way you're likely to be able to do it is to exploit a privilege escalation vulnerability to get root (as @Polynomial says), or exploit some other vulnerability in the system.


Is powershell being executed from within Javascript a security risk?

Node.js is a server-sided javascript implementation. It runs on a webserver, not in a browser. If anything, it can be used to open a powershell session on the server it is installed on.

So unless your client runs a webserver AND has node.js installed on that webserver AND has a script on it which uses the method described in the stackoverflow answer to have it run a powershell child-process AND has a vulnerability in that script which allows an attacker to inject arbitrary code into powershell, that's a quite unlikely attack vector.

For how the attacker learned the information you mentioned about your client's system: You aren't providing enough information to make a guess in that direction.


Why was DES with 112 bit keys (IBM) reduced to 56?

The NSA convinced IBM that 56 bits was "enough":

  But whereas Lucifer had a key that was 112 bits long, the DES key was shortened to 56 bits at the request of the National Security Agency.

from Practical UNIX & Internet Security

  In the development of DES, NSA convinced IBM that a reduced key size was sufficient

from Data Encryption Standard - Wikipedia

  The NSA made two changes to DES: It tweaked the algorithm, and it cut the key size by more than half.

from The Legacy of DES - Bruce Schneier


Electron Framework vulnerability - Explaining remote code execution

According to the CVE RCE is triggered when a specially crafted URL is clicked that will be handled by Electron. The vulnerability is only for Windows, and does not affect macOS or Linux. See the Electron team's blog post for more details.


It depends on what scenarios are relevant in your case, it depends on architecture that you want to implement. Some examples:

1) If in your case the risk of compromising of account with low permissions is higher compared to accounts with high permissions, then sending permission info in the token increases your risks.

2) If in your case all accounts can be equally easy (or equally hard) compromised, then sending permission info doesn't change your risks: The attacker will compromise an account with high permissions (e.g. admin account) and, even if permission/authorization logic is embedded in the application not in the token, he will get all permissions of this account.

3) If in your architecture you want to have "slim" application modules / services, that provide as high performance as possible, as small response times as possible, use as little resources as possible, or if integration with authorization / permission system is too expensive, then may be you want to eliminate any logic related to authorization / permissions in the modules / services that implement business logic. On some nodes you can deploy authentication and authorization services. On many other nodes you deploy (or run containers, doesn't matter) services that implement some business logic. And you may want that these services don't care about permissions and just trust the tokens that the other part of your application issued. Then sending permissions within tokens could be a good approach.


securities concerns about calling REST API from multiple servers

Question Restatement:

In application architecture, what is the most secure way way to delegate calls between Javascript APIs:

To allow the end-client to call the hosting API directly; or
To delegate the end-client's call through a front end-server.

Possible Context: This concern could be most applicable to Node.js where application logic is implemented via Javascript -- otherwise, I am still not certain I understand the question correctly ... :

Quick Answers:

Here are some links about securing REST APIs, hopefully to help focus the question a little -- but I am not certain if this is the question:

OWASP Security Cheat Sheet
https://stackoverflow.com/questions/7238094/securing-rest-api-without-reinventing-the-wheel
https://securityledger.com/2015/08/the-challenge-of-securing-rest-apis/

Answers - Multi-Tiered Architecture is Not Security:

Application Architecture is very different from "Secure Application Development".

No matter how you architect / structure / partition the functionality -- it will not secure the application -- but only allow the basic framework so you CAN secure it.

In your question, you are actually discussing "Multi-Tiered Architecture".

And, if not architected correctly -- you do preclude yourself from being able to secure the application.

These are the main principles of Multi-Tiered Application Architecture, that I think you are referring to:

Loosely Couple the Client and Presentation Logic to underlying Business and Integration Logic -- Decoupling completely from all Data Logic.
Loosely couple the Integration Logic, (B2B interfaces, etc), to Business Logic -- completely decoupled from Data Logic.
Loosely Couple the Business to Data Logic.
Never allow access from one tier, to the tier above -- only down ONE tier, (Presentation to Business, and Business access to Data, but not Presentation directly to Data, nor Integration directly to Data, but Integration to Business is fine.

However -- even when properly implemented -- you must secure the interfaces between each tier, otherwise -- it is just as vulnerable as if everything was running on the client.


How can I hide a DAO or ADODB connection string in a Word document or template?

Configure the database to use Windows authentication, then add IntegratedSecurity=true to the connection string.  This will have the connection use the logged-in user's authority to connect to the database.

This protects you in several ways.  As you require, no user/password is kept in the connection string.

Another way this protects you is that it's the user's authority that connects to the database, not some Word document.  That is important because the authority shouldn't travel around hidden inside a document.  The user controls their own authority.

Finally, if you're using Active Directory, you can use AD group membership to fine-tune the access to the database, ensuring only approved group members can use the Word document to access the database at whatever levels you desire.


Are there any FIPS140-2 requirements that apply when boot code is updated in the field?

I assume the question is about security level 1? There are various FIPS 140-2 level 1 compliant software modules on the market and they don't require the boot code to be authenticated. I believe security level 3 would require a full integrity check of the software including the boot code.

For a better understanding of what is required for FIPS 140-2 certification I would suggest taking a look at some of the security policies linked to on this page on the NIST site. If you find a product on that page which is similar to your own you can use their security policy document as a basis for your security policy.


MITM attack in a star network with proxy server

Security on a computer not controlled by you is relatively hard, but here's the best advice I can give:

Use strong authenticated encryption.  Whenever the question is "how do I protect against MITM attacks", the answer is always "use strong authenticated encryption."  For web browsing, this means TLS (HTTPS) without mixed content and with valid certificates.

Given that this is a community center computer, I'm not going to suggest techniques like using a VPN, TOR, or other proxies, since you're probably not in a position to be installing software.

Also, on a shared/public computer, you want to watch out for malware as much as possible.  Hopefully they use up-to-date anti-malware software.  (Again, on a computer not controlled by you, you don't have much ability to change this, but can at least be aware of the risk.)


Authentication using a digital signiture

Client: I wanna login!

Server: Okay. Here's a piece of data. Do something to it that only you could do!

Client: Okay. Here 's your data back. I've added a signature with my secret key.

Server: Lemme just check ... Okay, welcome in!

This is a less than formal description of a challenge-and-response authentication protocol that uses signature. ;)


Layered email encryption with multiple private keys on separate media

Note: This answer was posted before the question was migrated from Cryptography Stack Exchange.  As such, it only addresses the purely cryptographic aspects of the question.

What you could do is set up a single public/private key pair using e.g. RSA or (EC)DSA, and have your e-mail program store the public key and encrypt your messages using it.

You can then store the private key in a file successively encrypted using three other (public/private or symmetric) keys, and store those other keys in different locations.  Thus, in order to decrypt the messages, you'd first need to decrypt the private key, which would require all the other keys.

Alternatively, you could split the private key file into multiple shares using e.g. Shamir's secret sharing, and store the shares in separate locations.  One advantage of this method is that you could set up the secret sharing scheme to only require some predefined fraction of the shares in order to reconstruct the key.  For example, you could generate four shares such that any three of them would be enough for reconstructing the key; that way, you could still decrypt the messages even if you lost one share.

As for recommending a good e-mail client for encrypted messages, I'm afraid I can't help you much there.  In any case, it's really off topic for Cryptography Stack Exchange; you may get better answers to that part of your question at Super User or at Information Security Stack Exchange.


Does factory resetting a phone erase spyware?

Chances of malware surviving a factory reset are very, very small, but not zero.
If you have rooted your phone, there is a small chance that malware can copy itself to the system partition, so it would survive a factory reset. Some anti-theft software will do the same for legit reasons: if a thief steals a phone and performs a factory reset, the owner can still track the phone.
If you are resetting the phone, you can do a firmware upgrade: download the latest firmware package from the phone manufacturer, and follow the instructions to upgrade the firmware. This will wipe out any trace of anything on the phone.


I often use Tor for this kind of tunneling. If Tor works in your network environment, set up a hidden service. The directory /var/lib/tor (GNU/Linux) has a subdirectory for your hidden service. Inside is a file called hostname. You add a section in you .ssh/config:

Host *.onion
  ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

plus maybe other options. Now you can connect to your machine using ssh hidden-service-hostname.onion and no firewall will stop you.


Several points against the second model:

Hashing the password should take a significant amount of time, so as to slow down brute forcing in the event of a database leak. Checking a password on every request is a waste of resources.
Cookies can be vulnerable to XSS attacks, and having your password stolen is worse than having your session stolen (passwords aren't changed as often, and they tend to be reused on multiple sites).
Cookies are generally stored unencrypted on the client.
Sessions can't be easily invalidated, as it requires changing the password.
It's completely incompatible with any Single Sign-On system (thanks @CBHacking)

Storing the password hash instead of the password isn't much better, you solve the performance problem but you're still potentially leaking the password hash to be brute forced, and you can't easily invalidate sessions, or even tell them apart in the case of a user with multiple concurrent sessions.


Using nmap to bypass a firewall and perform OS fingerprinting

The answer depends on what you are targeting to some extent. If there is an Internet-facing port on the host your scan may be blocked by the firewall responding with resets (RST) which makes your initial scan results look closed or filtered even though that may not be entirely true. Firewalls are designed to make this harder and can block some scans but if at least one port is available for testing you have a very good chance of figuring it out.

That said you will have to focus on information like the type and versions of applications running on the system. Use nmap to focus on the ports that are open and increase verbosity and look at the service versions.

nmap -Pn -vvv -sV -p 80 #(webserver) or
nmap -Pn -vvv -sV -p 22 #(ssh, hopefully on another port)

and you
    will see outputs that include lines like

22/tcp open  ssh     syn-ack OpenSSH 5.9p1 Debian 5ubuntu1.8 (Ubuntu Linux; protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

This can help you identify the host even if general port scanning will not.

Note: you can also take this a step further by analyzing the protocol traffic itself or content available via the applications exposed.

Additionally an nmap FTP bounce scan can also scan other servers behind a firewall:

https://nmap.org/nsedoc/scripts/ftp-bounce.html

nmap -vvv -b -PN :@


What technical reasons are there to have low maximum password lengths?

Take five chimpanzees. Put them in a big cage. Suspend some bananas from the roof of the cage. Provide the chimpanzees with a stepladder. BUT also add a proximity detector to the bananas, so that when a chimp goes near the banana, water hoses are triggered and the whole cage is thoroughly soaked.

Soon, the chimps learn that the bananas and the stepladder are best ignored.

Now, remove one chimp, and replace it with a fresh one. That chimp knows nothing of the hoses. He sees the banana, notices the stepladder, and because he is a smart primate, he envisions himself stepping on the stepladder to reach the bananas. He then deftly grabs the stepladder... and the four other chimps spring on him and beat him squarely. He soon learns to ignore the stepladder.

Then, remove another chimp and replace it with a fresh one. The scenario occurs again; when he grabs the stepladder, he gets mauled by the four other chimps -- yes, including the previous "fresh" chimp. He has integrated the notion of "thou shallt not touch the stepladder".

Iterate. After some operations, you have five chimps who are ready to punch any chimp who would dare touch the stepladder -- and none of them knows why.

Originally, some developer, somewhere, was working on an old Unix system from the previous century, which used the old DES-based "crypt", actually a password hashing function derived from the DES block cipher. In that hashing function, only the first eight characters of the password are used (and only the low 7 bits of each character, as well). Subsequent characters are ignored. That's the banana.

The Internet is full of chimpanzees.


These types of question has depends answers. The answer varies depending on the policies of owner of open WiFi and plans among other factors.
but This question specially has 2 aspects: (second aspect may be your answer)

First one: connecting people to an open WiFi network, without having the owner's permission and following his/her terms of service is illegal.

Using a neighbor's wireless access point without the neighbour's permission is illegal.

the examples are:

Many U.S. states prohibit unauthorized access to computer networks including open Wi-Fi networks. While interpretations of these laws may vary, some precedents have been set:

2007 - a man in Michigan was fined for using the Wi-Fi hotspot of a local cafe, from his car.
2006 - Illinois man David Kauchak was fined for unauthorized use of a local agency's Wi-Fi access point.
2005 - a Florida man faced felony charges for piggybacking onto a neighbor's Internet connection without their permission.
Similar restrictions on using open Wi-Fi networks exist outside the U.S. as well:
2006 - In Singapore, a teenager received a probationary sentence for wirelessly. accessing a neighbor's Internet connection without their permission.
2005 - In the U.K., Gregory Straszkiewicz was fined and his computer confiscated for using a local resident's Internet service illicitly.

Therefore, as yours rights:Just as entering a home or business without the owner's permission is considered trespassing (even if the doors are unlocked), likewise accessing wireless Internet connections (even open access ones) can be considered an illegal activity. At a minimum, obtain consent from the operator of any Wi-Fi access point before using their service. Read any online Terms of Service documentation carefully when signing on, and contact the owner offline if necessary to ensure compliance.

So if people connect to your open WiFi whiteout your permission they accept the risks and your terms of services by default.

Second one:  if someone provides an open WiFi, specially for malicious proposes in some cases it can considered as crime. since your proposes are not malicious it is better that you consider a terms of service, in order to probable future states.

and also read this news:

Sniffing open WiFi networks is not wiretapping, judge says

Packet-Sniffing Laws Murky as Open Wi-Fi Proliferates

Public Wifi Data = Radio Waves Legally Accessible by Anyone


Can posting "howsecureismypassword" results be a security risk?

By posting those results, you are limiting the pool of guesses the person has to use. However, this does not make brute forcing faster in a practical way, it simply limits the guesses the person will try. With a strong password, this brings diminishing returns -- excluding guesses without numbers or symbols doesn't help all too much.

However there is one exception: if the site reports you're using a "commonly used password" then it makes brute forcing extremely fast. And if you're using a password from that list, you deserve it!


Securely displaying hidden integers with MD5

This very high end GPU cracker performs 200GH/s:

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

That's 200 billion hashes per second (2e11 hashes/s).  With a search space of 1e19 possible numbers, that means it will take ~500,000 seconds (about 1.5 years) to exhaustively search parameter space.  Of course on average you'll find a match in half of that time.

In short, MD5 is a fast algorithm, which normally means brute force is easy.  However in this case the large size of your search space negates a lot of that.

Depending on what happens for a successful user though, MD5 still might not be the best choice.  A top end hashing rig is too slow by a factor of ~200,000.  That seems like a lot, but you're basically asking "How long until my hardware might be 200,000x faster?".  While the growth pace of computer hardware has slowed, it's not unrealistic to expect that gap to shrink substantially in just a few years.

Finally, you also have to be concerned about weaknesses in pre-image resistance.  I haven't "checked in" on MD5's status in a while, but last I heard MD5 was still pre-image resistant.  Other aspects of MD5's cryptographic security have been broken (aka it is no longer collision resistant, although that is not relevant here).  Therefore, while MD5 is still pre-image resistant, that could change any day.  Without pre-image resistance an attacker might come up with a technique to find a payload that gives the same hash as your number, without having to actually brute-force the number.

In short, you are safe at the moment.  The safety margin though is perhaps not that high.  Whether or not you need to take action depends on what you are securing on the other side of this.


I see two problems with the proposal: normal users will not like it at all, and attackers will not find it hard to work around.

Usability is decreased in that any user must have his colleagues/friends around when he wants to log in. Multi-user approval is a valid model for initial registration (old-style clubs work that way: you can enter only if one or two existing members approve it) or when the system is especially critical (e.g. in a Titan II launch complex, two officers had to turn their "launch keys" simultaneously to trigger the ICBM lift-off), but for everyday tasks users will find it overly cumbersome. When users are employees, they will grumble and be unproductive; when users are customers, they will wander away.

Security is not much increased for the reason that you state at the end: even if the server sees the requests as coming from different users, it cannot check whether they come from different humans. Attackers who succeed in stealing some credentials can often steal several sets of credentials at the same time; for instance, if the attacker could plant a keylogger on a desktop computer, then he will grab all the passwords typed on that computer. If multi-login is enforced, then it is probable that in many cases, the two involved users will type their passwords on the same computer ("Hey, Bob, while you're here, would you type in your password ? I must update sales report 6X42.").

This contrasts with two-factor authentication in which the user login is controlled by two distinct types of credentials. The extra security comes from this type diversity; requiring authentication from two distinct users does not provide this type diversity.


PHP Vulnerability May Halt Millions of Servers - max_input_vars!

Interesting article (CVE-2011-4885 for those who like references), thanks for the heads up - I'll be reading up on this but a few points stand out already.

just to clarify - the problem is within the logic tier - not the webserver itself.
your question of whether it is possible to use ini_set is predicated on the underlying PHP engine having been upgraded - when you've already argued that this is unlikely to happen for a lot of hosting providers. OTOH any hosting provider who does upgrade their PHP is likely to deploy the related ini changes or provide a mechanism for doing so.
while most hosting companies will actively avoid imposing a major upgrade on their users, they should be deploying vendor patches to existing deployments - and this patch has already been backported to all production versions of 5.3 and 5.2, I believe that Redhat have now released patches for current RHEL
there are at least 4 different places ini settings can be changed in PHP - in the php.ini file, in the webserver config (when PHP is implemented as a module), in .htaccess files (again if module) and in the PHP code itself - but not all setings can be changed in all places - so far the new config var is not in the manual to say where it can be changed.
in order to exploit this vulnerability, it would be necessary to send a significant amount of variables in the request - Apache (and probably most other webservers) allows some control over the total size of the request, request body, and POST data - also execution time - effective and selective use of these config options in both the httpd config and for specific directory trees using .htaccess could be used to mitigate any potential attack - bearing in mind any need to support (e.g.) file uploads.
the nature of a DOS based on this vulnerability is, in effect, very similar to the problem with range requests on Apache (CVE-2011-3192) - although a serious vulnerability, I've not seen much evidence of that defect being widely exploited.

  I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site

I don't understand - certainly an attack based on this vulnerability will not result in leakage nor modification of data / code (AFAICS).


I tried to break my WiFi: is 8 uppercase letter strong enough?

Personally, I don't think that 8 character (uppercase) is strong enough to withstand a determined attacker. Using only uppercase characters we have,

268 = 208827064576 possible permutations.

If we add lowercase to the mix we can increase this to

528 = 5.3459729e+13 permutations.

As you can see by increasing the character set we increase the amount of time required to bruteforce by a massive amount. I personally recomend using an alpha-numeric PSK that is 12 characters minimum.

Researchers show the practical implications of weak PSKs in the following entry with a budget of only 200(Euros),

https://www.exploit-db.com/exploits/34307/

The biggest bottleneck most people would have is the harddrive size however it's relatively cheap to buy harddrives large enough to make this feasible. Using modern hardware and a bigger budget it would be trivial to bruteforce an 8 character uppercase PSK assuming the attacker can capture a successful authentication.

So as people, and yourself, have mentioned this will stop ametures from brute forcing the PSK. Anyone willing to put in the time to do this attack over the span of a few days will very likely not be an amateur.


How much more secure is fingerprint compared to text passwords?

Fingerprints are not supposed to be used on their own for authentication. The fact that many devices are starting to do that does not mean it is a good idea. In security, you should authenticate yourself with three different factors: something you have, something you know, and something you are. You can have a smart card, or an encrypted hard disk. You can know a secret password, a pin, or a pattern. And you are a person with a fingerprint, a person with a particular typing pattern, or a person with a specific speech pattern. Often, people only use the latter two, for example a username (something you are) and a password (something you know). See these lecture notes. It explains this all very well.

A fingerprint is like a username. All a username does is allow authentication using a non-secret value so there is no issue with "error: this password is already taken". Less information is revealed when the message is "error: this username is already taken". This is the purpose of the username. But how is a fingerprint the same? A username is something easy to discover, usually it's plastered all around or simply a variation on a person's name. A fingerprint is the same. It is plastered all around. You don't need high-tech forensic equipment to pull a fingerprint off of anything. While some devices try to use slightly more advanced fingerprint scanners (e.g. using capacitance detectors to avoid being tricked by high-res photos of a fingerprint), they are still not all that good.

Finally, you asked how fingerprints compare mathematically. This cannot be answered because a fingerprint is not a mathematical value. You would have to see how the specific implementation of fingerprint reader works. How many unique points on a fingerprint does it take into account? What is the variation among different populations for these specific points? With a password, the strength is simply the equivalent of the amount of entropy present in the password. Unlike fingerprints, passwords can be made truly random.

A fingerprint is a username that you don't have to type in every time.


Storing encryption passphrases in memory in Dalvik?

In Java the memory management is completely under the control of the VM. You can never be 100% sure what the VM does with its memory, because that's completely up to the implementation. However, there are things you can do to discourage the VM from caching.

Just null-ing a reference is not a good way to persuade the VM to remove something from memory. It will take at least until the next garbage collector sweep until the data is collected. With the class String you also have the problem that the Java specification mandates string pooling (multiple strings with identical content are mandated to use the same memory). This could be a reason for the VM to cache a string in memory even when there are no references to it.

What you could do instead is go the low-level C way and store your password in a char[]. There isn't much reason for the JVM to do much abstraction on arrays of primitives. When you overwrite each entry of a char-array with nul-characters, it is quite unlikely that the JVM will keep a copy of the original content.


When is it acceptable to use self-sign cert in production?

Encryption: Perfectly OK to use self-signed as there no chain trust
  required. In case of an attack, the MIM cert will simply not decrypt,
  no other impact.

That is not correct. Trust needs to be established for encryption using a public keys, but it is on the other end. The encryptor needs to trust the encryption certificate, since otherwise he would be encrypting his sensitive data for some stranger to decrypt and read.

I think that your categorisation is the wrong take on the matter. The important question that you need to answer, if you want to use a self signed certificate (or even a non-publically trusted PKI) is: How will I be able to make my communication partners trust my certificate?

This could be done via a company policy (for company internal TLS certificates), via direct communication (for securing messages with a very small group of people) or it cold even be unneccesary since you control both ends of the communication (e.g. an app you wrote which communicates with a server you run).

There are more scenarios than the ones that I have listed, but not that many. If you ever have to rely on some unknown user having to actively do something, than you really should not use self signed certificates.


How to get help from an ISP to take down a phishing campaign?

Did you try the Goverment CERT in your country? In my experience they can be pretty helpful in such cases and usually have the right contacts at ISPs to initiate a takedown


Trouble understand login vulnerabilities

Both cases are serious vulnerabilities, and the security approach is wrong.

First of all, the form itself shouldn't escape anything. You might want to check the input, but you do not manipulate it. Escaping is done in a specific context like a database query, not globally.

No, it's not secure to simply prepend a backslash to single quotes in the application:

Database systems support different character encodings which may or may not match the encoding used by your application. If they don't match, the escaping attempt is essentially a shot in the dark and may not work at all. There's a famous injection attack which exploits the differences between two common character encodings. The only way to be sure is to use an encoding-aware library function of your database system. For example, MySQL has mysql_real_escape_string().
Backslash-escaping is a nonstandard mechanism which only works in some special modes of some database systems (like MySQL). If the server configuration or the underlying database change, you may again lose all protection.
There are much more characters that you need to take care of. This also depends on the database system and its configuration.

Manual SQL-escaping is actually a rather poor approach, because it's complicated, tedious and error-prone (as you can see). A more modern solution is to use prepared statements and not stuff any user data into SQL queries in the first place. If, for some reason, prepared statements are not an option, make sure to use the right library function instead of trying to invent your own solution.

Your second case is a full-blown cross-site scripting vulnerability, so an attacker can do anything which is possible with XSS (like stealing a session cookie). No, XSS is not limited to URLs in any way. You've just proved that yourself. An XSS attack happens when a user is able to inject data into an HTML context. Where that data comes from is irrelevant; could be the URL, could be a form paramater, could be a cookie, an HTTP header, a database string, anything.


Is it possible to completely wipe a flash memory?

This topic has already been covered here and there. To sum up:

If you simply overwrite the complete disk (as a block) with data (random, null bytes... it does not matter), then there may be parts of surviving data, which could potentially be recovered by extracting the chip and reading from it directly.
You cannot know what data has survived without taking the chip apart.
Overwriting the whole disk repeatedly should eradicate (almost) all the data, but you cannot be sure of it, and it will severely diminish the lifetime of the card.

It is safer, and (in the long time) cheaper, to simply physically destroy the card. Next time, use disk encryption.


How do I validate a certificate by hand?

Copy all CA certificates in PEM format including root into a single file. Certificate can be mostly in one of these two formats: PEM format is text, DER is binary. If it is in DER - can convert this way:

openssl x509 -in <certificate in DER> -inform DER -out <certificate in PEM> -outform PEM

Then concatenate all CA certificates in PEM format into a single file:

cat cert1.cer >> all_certs.cer
cat cert2.cer >> all_certs.cer

Then validate your certificate against this certificate chain:

openssl verify -CAfile all_certs.cer <your certificate>


If you have a rooted device , and if any application stores password in clear text in their database , then yes , you can view them if you have root access. About sending messages as a different user ,it depends on how that particular app works . Lets consider that FB USES A DB for maintaining all the messages which needs to be sync'ed once the device is online. Since you have root access , you can make ur own entry in that particular table and messenger would happily sync it once the phone is online. All this is possible if the database of the application is not encrypted, if not , you will have to find out the encryption key and then replace the database after making the necessary modifications. To find the encryption key , you can reverse engineer the application or use run-time hooking methods , like the once offered by cydia substrate to do your bidding .


Random pages getting created on classic asp site

It could be that your site has become a victim of attackers and that it has been compromised. The best way to deal with this is to take down your website completely (shut down the webserver as it might be used for malicious intent) and restore backup from when you knew it was not compromised.

Before putting your site online again find out how the attackers managed to get into your site or how they managed to produce these files. I suspect you have a vulnerability in your webapplication or in your webserver.

If this is a shared environment contact your hosting provider.


Why does bettercap and sslstrip work sometimes on Google and Facebook?

According to the documentation, this works by rewriting HTTPS links to HTTP links with a different subdomain. Since none of these sites use the includeSubDomains directive, the browser won't use HSTS for these rewritten links. Using the includeSubDomains directive prevents this attack by having browsers force the use of HTTPS for all subdomains of a site, instead of just certain subdomains.

Normally this shouldn't work for preloaded sites, given that the preload list requires that includeSubDomains be specified, but it appears the list has made certain exceptions to that requirement, notably for Google and Facebook. Google has a long list of subdomains preloaded including accounts.google.com, docs.google.com, encrypted.gogole.com, etc, but google.com is not preloaded. Likewise Facebook has www.facebook.com, m.facebook.com, secure.facebook.com, and several others preloaded, but facebook.com is not. Thus if you're already on an HTTP site, sslstrip2 can rewrite a link from www.facebook.com to wwww.facebook.com to avoid HSTS.

While testing this I discovered that Firefox's preload list also differs from Chrome's more than one might expect. As noted here, Firefox's list is based on Chrome's, but Firefox does its own validation of the list. This results in cases like touch.facebook.com, where Chrome has includeSubdomains set to true in its preload list, but Firefox has it set to false (indeed when I just tested it the header I got was strict-transport-security max-age=15552000; preload).


single secure architecture solution for below 4 threats

The easiest, cheapest, and most secure way to deal with credit card data and remain PCI compliant for small business is not to deal with credit card data. Use a third party payment provider like Paypal, Stripe, Google Wallet, eWAY, Braintree, etc so you don't have to deal with securing the credit card data. Many of these payment processors also has features for preauthorized transactions for future transactions and subscriptions.


Where can I find a collection of Threat Models?

SANS.org have a few really good resources. Including:

http://www.sans.org/windows-security/2009/07/11/practical-risk-analysis-spreadsheet/
http://software-security.sans.org/resources/paper/reading-room/threat-modeling-process-ensure-application-security
http://www.sans.org/reading_room/whitepapers/securecode/threat-modeling-process-ensure-application-security_1646

Also for web application try https://www.owasp.org/index.php/Threat_Risk_Modeling.


How does Domain Fronting work in practice

If Amazon has already banned fronting why is it possible to successfully make the above request?

Amazon hasn't banned domain fronting yet.

  At a practical level, how can a malicious user leverage fronting for hosting a malware C&C service?

Without domain-fronting, proxies can see the target host via SNI, and can choose to block the request to protect the user.

Domain-fronting works since it's faking the host in SNI. If the fake host is important enough, like google.com, the traffic won't be blocked.

  Can an individual customer ensure his subdomain (say xyzabc.cloudfront.com) is not susceptible to fronting?

Create another subdomain on the same host, and use cURL to check:

curl -s -H "Host: subdomain2.host.com" -H "Connection: close" "https://subdomain1.host.com/"


Can I hide my location whilst using mine and my company's VPN?

Depending on your operating system and TCP/IP stack, it's not so clear-cut that you can. Running two VPNs requires establishing which is the "inner" and which is the "outer" VPN, and this means the two software drivers might need to collaborate to some extent.
At the most basic level, some VPN softwares (and your company's might well be one of those) require that the carrier interface is physical (i.e. not a VPN itself).
However, as I see it, if your company allows you to work through VPN this means that they should not be concerned about where you're connecting from. That is the point of a VPN. So, have you tried asking? They might be all right with allowing you to work from wherever you wish, provided the work gets done. Actually, this once happened to me, they might be ecstatic and assign you to some specific task that would benefit from the different time zone (or exempt you from Skype calls at certain awkward times).
And on the other hand, if your company only allows specific places to act as VPN endpoints, this means they require the additional security - they might not want you to get your laptop screen in any old Internet café where someone might be able to snoop from behind your shoulder. If this is the case, it stands to reason that they will have instrumentation in place to help detect non-compliances: the simplest one is check out from which IP you're connecting.
In which case, if you fire up your private VPN from anywhere in the world, including your own home, and thus appear to be located in PrivateVPN's rack space, the fact you're nesting two VPNs will be immediately obvious and trigger some alarm.
Also, in the case of the time zone, you might find yourself forced to stay awake at night, or be unexplainably unavailable during normal workhours when your colleagues might wish to communicate with you.


Attack using 100 Mbps link means you have to create roughly 210k packets to fully utilize your 100 Mbps connection.

100 Mbps = 12500000 Bytes

12500000 / 60 Bytes = 208333.3333333333 Packets

Depending on your machine you will require multiple processes to generate this amount of packets, single process won't generate these many packets in one second.


Is phishing ineffective against a Gmail account that has 2FA?

"Phishing" is a broad term for online social engineering attacks where the attacker impersonates somebody the victim trusts. Phishing attacks can have many goals; basically anything that the the user could be persuaded to do on behalf of the impersonated entity. 2FA protects against certain attacks, and some forms of 2FA provide better protection than others, but it's not a perfect solution.

Attacker wants credentials: get the user to enter their credentials in a web form that appears to be a trusted site. This alone won't give the attacker access to the account if the account has 2FA, but we never specified "access to the account", merely "credentials".
Attacker wants access to the account: spoof the trusted login page, and then simultaneously try to log in with the captured credentials (and forward back any user-facing prompts) so the user sees the expected 2FA behavior and approves the login / enters their access code. (This doesn't work for FIDO/U2F, but the attacker can try having their spoofed login page complain that the security key isn't working and the victim should use an alternate authentication method.)
Attacker wants access to the account contents (emails, etc.): Convince the victim to authorize an app (maybe call it "Gmail Privacy Protection" or similar) that the attacker controls, and that gets access to the user's mailbox (this exact kind of attack went around less than 3 years ago with an app spoofing Google Docs integration and then forwarding itself as a worm).
Attacker wants to control the victim's browser: get the victim to install a browser extension from a "trusted" source.
Attacker wants to take over / compromise (perhaps with ransomware) the victim's whole computer: convince the victim to run a program written/distributed by a "trusted" source.
Attacker wants the victim to send them $2500 in gift cards (this is a more common attack than you might think): convince the victim you're their boss, tell them to buy the gift cards with their corporate account and that it's covered, and to send them to somebody that is a plausible recipient (a corporate partner, or an internal team running a prize event, or whatever) but with the wrong address.
Attacker wants... you get the idea.

Phishing your credentials is like XSSing your session token. It's obvious and scary and a perfectly legitimate target, but it's far from the only thing the attacker can do, and mitigations that specifically protect against that goal usually do little or nothing to prevent other goals. FIDO/U2F security keys provide excellent protection against web-based phishing pages, but you need to use them consistently. They provide no protection against you authorizing access to an app, running code (either in a sandbox like your browser / phone, or on your computer directly), or other attacks that don't directly involve stealing the victim's credentials or login session.


Is restricting a Google API key for an Android app useless?

As domenukk stated in his comment, the Google API key restriction prevents other users from packaging your API key in their app. It is simply a way for Google to ensure that the API calls it is receiving are coming from an application that was packaged by the developer who added said key to his Google API account.
However, as you rightly pointed out, it is easy to circumvent. For example, this answer on SO shows how to build a request using any Android Google API key. So the matter of circumventing the restriction is rather trivial.
However, the benefit is in the cost involved for an attacker. A similar question was asked for HTTP referrers, so I will just quote the relevant part to your question (just replace referrer header with SHA1 fingerprint):

So, just because a malicious agent could copy the referrer header, they may not have the time or inclination to do so. Think of a valid referrer header like a concert wristband. Can you forge them, or sneak around the guard checking wristbands? Sure you can, but it doesn't make the band useless.
It raises the cost for the attacker.


The various "patches" which have been applied on SSL/TLS have the nice characteristic of not changing the on-the-wire protocol: they are implementation tricks which work around the issues implied by MAC-then-encrypt. One way to say it is that it is possible to implement and use MAC-then-encrypt securely, but it is not easy.

This backward compatibility with the existing protocol allowed the patches to be implemented and distributed and used right away, whereas a new protocol would have taken years to be widely adopted. For instance, problems with CBC mode in TLS 1.0 (what the "BEAST attack" leverages) have been fixed by a new protocol version (TLS 1.1) since 2006, but browsers have begun to support it only about 2 years ago, and a large proportion of Web servers still don't support it. A new protocol which fixes issues does not do any good if you cannot use it, because it is not supported on the other side of the connection...

Apart from waiting for a yet-to-be-defined TLS 1.3, which could take some time to be specified, let alone implemented and supported, you might have some luck with TLS 1.2, which supports GCM. GCM is an encryption mode which combines symmetric encryption and a MAC, and does it properly (i.e. MAC-then-encrypt, roughly speaking). Of course, not a lot of browsers and server support it yet, but at least the specification/approval part is done for these cipher suites.


Is chain hashing algorithms the ultimate solution for hashing passwords?

... but at the end a powerful machine/s targeting one important password can crack it

If you mean with "at the end" in a couple of 1000 years then you might be right. The main point of salting and slowness is that it is practically infeasible to build rainbow tables (would be too big due to salting) or to brute-force good passwords (would be too slow due to slow hash). There is no need to add yet another layer on top of this.

And essentially what you propose is to just replace a slow hash with an even slower hash. This can already be achieved by just using more rounds in the existing password hashing algorithms, i.e. they have these feature already build in.


SSO: Who is the idp (identity provider) for Google Apps?

Basically, yes. Any Google-based app uses a Google Id for authentication. As such, they are their own IdP.

You can additionally federate to Google with your own IdP as well if you are an enterprise user. It would work along the lines of:

Your IdP => Google Id (gIdP) => GMail


Is it safe to use Memcached in a shared hosting environment?

If you did not configure it, then you can't know if its secure. Doesn't matter if we're talking about memcached, an Oracle database, opensshd....

As grochmal says, there are no intrinsic access control mechanism in memcache. So there is very little scope for the service provider to implement the kind of partitioning you might desire.

Encrypting all the data you store in memcache would solve the disclosure problem (but creates a key management problem). It doesn't prevent damage to the data.

  are there any other options for me to use cache the data results

We don't know what the hosting is nor what your requirements for security are. If "the data" is a mysql result set, then you use mysql's caching. If its JSON data fetched via HTTP then you may be able to use a forward proxy. If its caching the output of your own pages, then a reverse proxy.....


Are you talking about the connection between the MTA and MUA? If so then the the possible attack would be downgrade attacks on the secure channel during the handshake. But as you say, unless you are being actively attacked, the OS/MUA should negotiate at the highest supported cipher suite


Is it possible to recover data from a Western Digital TRIM supporting disks (not SSD) after quick format?

Yes, I can assure you with 100% confidence there is definitely ways to retrieve the information. If you rewrite over the sectors of data too many times or just pass over them to wipe the drive, then it would no longer be possible. There's just one downfall to the information I'm providing - the way I've retrieved deleted data (from formatted disks, emptied recycle bins, corrupted and/or failed disk drives) involves recovery software that typically has a price attached to it.

However, you may be able to retrieve the full extent of your files and data just with the trial versions. Stellar-Phoenix is the main software I use, though not for any particular reason. Other programs I've used include DMDE (Disk Editor & Data Recovery), EaseUS Data Recovery, and ... now that I'm looking, I think this one IS free:

TestDisk  -  TestDisk & PhotoRec

Be aware, though, having used testdisk 3-4 different times myself, it creates quite a large number of directories and - for whatever reason - accumulates far more GB of space during its recovery process than any of the other software I used. BUT ... it definitely works. I just hope you have a specific file type or perhaps have knowledge of a programming language that can help you sift through the mountain of directories it creates.

At any rate, I hope this helps! I skimmed the testdisk website and confirmed it is, indeed, free, open source, and works.

Unfortunately, I'm doubtful any of the software I mentioned above can recover firmware "tweaks", although would it not be possible to perform the same tweaks again? On the other hand, I am unaware as to the extent of said "tweaks". At any rate, good luck! Hopefully you can get back to the same, familiar system it once was.


In Nmap: can we specify the --version-intensity option with A option?

Yes, you can. Under the hood, -A is simply an alias for a number of other flags, including -sV which enables version scanning. User-specified control arguments are given precedence over defaults (if any) set by such flags.

As an example, -T4 sets a timing template including --max-rtt-timeout 1250ms, --initial-rtt-timeout 500ms, and --max-retries 6. However, you can manually specify any of these in addition to the -T4 flag to override these defaults.


Possible Scam - reply address appears to be yours

Scam.

Like many such messages, it seems to be a very similar to several other variants of this type of message as seen by searching pieces of information in the email.
The messages I have found that match this almost to the word have at least three different "Administrative Clerks" signing off on them.
38 Roxboro Road, Limerick, Ireland (to the best that I can find out) is the back side of Limerick Prison. The nearest court does share a street with Limerick Prison, but it isn't Roxboro.
+353 800 814 250 doesn't appear to be a valid toll free number for Ireland where the closest match for toll free numbers is 1800, so I assume a North American author found an Irish reference and falsely assumed that the 1 could be dropped.

I could keep digging, but if I had received this I would be fully comfortable calling this a scam and moving on.


Depends on the attack you want to generate(Attack type), the capacity of your single host (CPU, Memory), and on the network capacity (Bandwidth), and also on the application that is receiving the requests in the case is a L7 attack, and probably more variables to take into consideration.


Extract the content of PKCS7 file in Java

Finally I did it with BouncyCastle library.

PKCS#7 is a complex format, also called CMS. Sun JCE has no direct support to PKCS#7.

This is the code that I used to extract my content:

// Loading the file first
   File f = new File("myFile.p7b");
   byte[] buffer = new byte[(int) f.length()];
   DataInputStream in = new DataInputStream(new FileInputStream(f));
   in.readFully(buffer);
   in.close();

   //Corresponding class of signed_data is CMSSignedData
   CMSSignedData signature = new CMSSignedData(buffer);
   Store cs = signature.getCertificates();
   SignerInformationStore signers = signature.getSignerInfos();
   Collection c = signers.getSigners();
   Iterator it = c.iterator();

   //the following array will contain the content of xml document
   byte[] data = null;

   while (it.hasNext()) {
        SignerInformation signer = (SignerInformation) it.next();
        Collection certCollection = cs.getMatches(signer.getSID());
        Iterator certIt = certCollection.iterator();
        X509CertificateHolder cert = (X509CertificateHolder) certIt.next();

        CMSProcessable sc = signature.getSignedContent();
        data = (byte[]) sc.getContent();
    }

If you want to verify the signature of this PKCS7 file against X509 certificate, you must add the following code to the while loop:

// ************************************************************* //
// ********************* Verify signature ********************** //
//get CA public key
// Create a X509 certificat
CertificateFactory certificatefactory = CertificateFactory.getInstance("X.509");

// Open the certificate file
FileInputStream fileinputstream = new FileInputStream("myCA.cert");

//get CA public key
PublicKey pk = certificatefactory.generateCertificate(fileinputstream).getPublicKey();

X509Certificate myCA = new JcaX509CertificateConverter().setProvider("BC").getCertificate(cert);

myCA.verify(pk);
System.out.println("Verfication done successfully ");