WAF Process Creation for Integration of IT and Business

1.Are those three processes (in)appropriate or am I missing any step/process of the whole thing?

Do you have a need to inspect SSL encrypted traffic?  Depending on where your WAF is positioned in your network, you may need a process to handle certificate provisioning and renewal with respect to how the WAFviews traffic.

I separate it into these areas:

Reacting to a potential incident

Research/forensics of detected event
Response to event

Determining correct approach to a true incident - your Process 1
Reducing the cases for false positives

Managing Change

new apps
big changes to old apps
small changes to old apps

Managing overall health

troubleshooting
upgrades
business continuity

2.Is it really better to have one process addressing all these issues, or should they be kept as three (or more) separate processes?

This has a lot to do with how you typically document processes.  As someone who works in simply ENORMOUS infrastructures and organizations, I'm always working within a hierarchy of paperwork, process and documentation - and anything you might provide in such a world, is better when it fits with the existing model.  Make it weird and people won't understand it or use it.

For a growing organization that is currently smallish, but hoping to be bigger - my big caveat is that the first breakout should be organization or discipline related, and each process is grouped by the trigger that causes it.  So, ideally, you end up with chunks that are isolated as clearly as the people are.

My experience is that operational folks and developers are such different gene pools that they almost count as different species.  They may use similar words, but how they approach a single tool, protocol or idea can be radically different.  For this reason, my first breakdown would be there:

1 - Ops Guide - available to the operations team, preferably folded into existing processes for things like firewalls.

what to do when an incident is detected by the WAF

known likely cases
unknown process (what to do when you don't know where to start)
includes handoffs to developers - where do you go to write a bug report for a false positive?  What do you do when you need a developer to help you research the issue? etc.

guidelines for scope of resonsibility
guidelines for managing risk and when/where to get approval on a risk

2 - WAF Maintenance guide - for which ever team is maintaining this component.  WAFs are funny - could be your boundary control guys (the firewall gang), could be web server support, could be something else.  Depends on the architecture and the organization

3 - Software Deployment & Maintenance - for any server protected by a WAF - how to deploy software to a WAF protected site, how to help debug a WAF incident.

Basically separate process to the extent where you can link them to the places where people working with WAFs or web servers will normally look.

3.Does anyone ever come across of a Tracker and/or Questionnaire template or have any suggestions on how I should lay them out? So far I thought of having one Tracker workbook plus one Questionnaire with three different tabs each, one for each sub-process.

Not that I can share.  I use corporate protected formats for most of this.

4.Is there a better way of doing this?

Realize, in addition, that what ever you create here is a living document.  It may be an XSS attack today, it may be something different tomorrow.  You want to create processes that build a knowledge store, automation where possible, and a way to clearly communicate (both in a crisis and to prevent a crisis).

5.Finally, how should be business' grounds for making a decision of whether to block an IP or not?

WAFs block a lot more than IPs - if you specifically look for IPs, I think you are trying to block individual trees in a forest.  For IP blocking, specifically, I'd think that any organization using a WAF is also using a firewall, and IP blocking would be managed in a way consistent with any firewall type process for the same thing.

Risk-wise, across the board - there should ideally be a consistent structure regardless of the nature of the risk - blocking the behavior of known bad attackers, blocking vulnerabilities of known attack profiles, etc. - there should be an entity at a fairly high level whose job is to weigh the risks.  The tradeoffs boil down to:

the risk to security of the overall system and business to leaving the weakness in place (allowing what you are currently allowing)
the risk to business operations in strengthing defenses - what can't you do when you block the threat?
the cost to doing it/not doing it

The person making the decision is usually a high level person who can take accountability within the organization.  Often it's the ISO - Information Security Officer.  But someone who is high up enough to see the business and not just the IT side if it.  Chances are that some stuff will boil up into general guidelines - so this person isn't going IP by IP - he's setting out some rules - if the IP attacks are bigger than some metric, definitely block... etc.


Why would I 'have been pwned' on a website that I never had an account on?

The main thing for this is because databases that got compromised did contain information that came from other websites you were registered on.


How does Google Chrome's JS Crypto RNG Work?

On POSIX, Google Chrome does in fact use /dev/urandom:

class URandomFd {
    public:
        URandomFd() : fd_(open("/dev/urandom", O_RDONLY)) {
            DCHECK_GE(fd_, 0) << "Cannot open /dev/urandom: " << errno;
        }

    ~URandomFd() { close(fd_); }

    int fd() const { return fd_; }

    private:
        const int fd_;
};

// ...

void RandBytes(void* output, size_t output_length) {
    const int urandom_fd = g_urandom_fd.Pointer()->fd();
    const bool success =
        ReadFromFD(urandom_fd, static_cast<char*>(output), output_length);
    CHECK(success);
}


How do I use hashcat to recover password from ata drive lock

No need for hashcat. From my answer here:

[...] at the ATA Secure Erase level, you should be able to initiate a
new erase with a new master password, regardless of what the old
password was.

This destroys all existing data, as designed by the ATA Secure Erase specification. But then you can use the drive again when it's done.


Microservice security: How to perform authorization + services also need auth checks individually?

I do not see the problem in authentication it's more authorization.

Legit solution is to enforce networking rules with iptables so any traffic besides api gateway is not allowed only from api gateway.

One of security rules is to take care of attack vectors which in your case is api gateway.
For more security you should check business logic on api gateway if privilege escalation is possible and if so implement authorization inside.

Why is it fine to have auth only on api gateway:

If attacker privilege escalates api gateway and grabs some subset of JWT-s there impact is near to same as api gateway having full access to services.
If attacker obtains JWT for some resource over api gateway there isn't any mechanism to stop him using the sam JWT on internal services if he gains access you adds a bottleneck to app

If your paranoia is big enough make sure to SSL encrypt traffic between api gateway and other services and iptables should be enough:
 - On same host: localhost port -> services endpoints
 - Different hosts: public static ip -> services public static ip/ips.

More info on subject look for threat modelling: https://www.owasp.org/index.php/Application_Threat_Modeling


Can freezing the browser be considered a security vulnerability?

Freezing a browser is a "Denial of Service" attack to an extent. You are "denying" someone usage of a service, in this case an application. A vulnerability that leads to a Denial of Service. I have done this in the past as a proof of concept against "IE" with a divide by zero javascript.

Most vendors that offer bug bounties offer them based on the ability to exploit a vulnerability in such a manner that could lead to "code execution", "data loss" or something along those lines. Most vendors will tell you "what" they are looking for with their bug bounty programs in their FAQs. Crashing a browser is more of a DoS, developer issue versus an exploitable (oh you can trigger code execution!) one.

So that answers your question but just in case, here is Mozilla's FAQ:

Security bug must be original and previously unreported.
Security bug must be a remote exploit, compromise user data, allow
access to Mozilla infrastructure or resources, or easily manipulate a
user.
Submitter must not be the author of the buggy code nor otherwise
involved in its contribution to the Mozilla project (such as by
providing check-in reviews).
Employees of the Mozilla Foundation and its subsidiaries are
ineligible.


Some browsers like Chrome have anti-XSS features which block obvious attacks. If you open the JavaScript console of your browser, you should see the warnings.

Either turn off the protection temporarily or use a different browser.


Is there a way to use public mail and not to enable the provider to see its content?

The only way you would be able to prevent your email provider from reading your email content is to encode it, that is to change it from its original. You could use an encryption software, however that would require software running on both sides. There is free software out there to do this, but it requires that the sending and receiving sides use a common protocol.

You could change the content of the email my using some sort of code, like a markup language or word substitution which is know by both sides. This would hide the intention of the message but still be readable by the email provider. Any ads you get would be based on the text in the message. This would be a lot of trouble to implement, and again require both sides to be involved.

I suppose you could write a self-contained program which would run without requiring software to be installed on the recipient's computer. It could contain an encrypted message and have decryption software built-in. That would prevent the content from being automatically scanned.

Free email services make money by offering ads, if you want add-free email then use a paid service which promises not to read your email.


Is it possible to steal WPA2 key using a rogue AP?

No.  The "WPA key" (actually PSK) is never sent to or from the AP.  The client and server both independently generate the PSK from the passphrase and SSID.  As part of the handshake the client and server will both encrypt data with the PSK and send it to the other entity.  That data is used to create the session key for encrypting all subsequent data between a specific client and AP pair.

The client and server authenticate each other by confirming the handshake data can be decrypted with the expected key.  A rogue AP or client will not be able to do that without already knowing the PSK.  Without the handshake any data sent by an entity without the PSK will not be properly decrypted which is how the counterparty identifies it as invalid.

The behavior on the client would be no different than what happens if the client is using the wrong passphrase.  Now a rogue AP could perform a denial of service attack on the client by preventing the client from establishing a good connection with the real AP.  This is especially true if the rogue AP signal is stronger as measured from the client.


Each anti-malware company develops their own databases for this kind of thing. You would have to look up that entry on each vendor's db in order to better understand what it is.


I mistyped a `pip install` command. Could my system have been compromised?

Any time you run pip install, your machine could be compromised if the package is malicious.
Looking at the code in that package, it does indeed appear to be empty. However, the installed code would not run unless you ran it manually. The more likely location for auto-run malicious code is the setup.py packaging script that is run during install; however, nothing malicious appears there either, assuming I am looking at the exact same version.
I suppose it could have been possible for a sophisticated attack that ran malicious code in setup.py during the install that removes the malicious code so you can't find it, and also reaches out to some remote server to update the version in PyPi as well. However, that seems like a very limited attack since it would probably only work once per package name, and the version history is available on PyPi. It's more likely that you installed someone's abandoned project.
It is good to be aware of what packages you are installing, especially since pip and other package managers have a history of actors using typosquatting to distribute malware.
If you want to avoid this issue in the future when working on your own packages, consider using pip install . from the top level directory of your project.


Is Apple Face ID a good security feature?

All security mechanisms feature a trade-off between usuability and security and I don't think that FaceID will be any different in this regard.

One of Apple's original motivations in introducing TouchID was to get iOS users who had no PIN code set at all, to use some form of security mechanism on their device.  This would obviously only work if the mechanism had good usuability, which TouchID does.

As to the specific threat you mention about creation of models, from technical information revealed by Apple so far, they appear to be using 3D mapping techniques combined with motion detection to identify the user (there has been mention that it won't work when your eyes are closed, for example).

So to copy that a full 3D model of the user would be needed and that model would need to emulate the users liveness to some degree.

So that's obviously a theoretical possibility, but the question is what level of effort would be needed for an attacker to pull this off, and whether that's a reasonable security/usuability trade-off for most iPhone users.

I'd suggest that if we're at "create an accurate 3D animatronic head to crack" that's not an unreasonable level of security for most users, if it has good usability (to quote @avid's rule of security "Security at the expense of usability, comes at the expense of security.")

If however when it's released, it turns out there's some simpler way of faking it out, that might be more of a concern.

Having seen Windows Hello in action, I'll be more interested to see what the False Rejection Rate is like with this.  Hello is great in fairly static settings, but not so good outdoors with things like hats and sunglasses coming into play.


How long does information stay vulnerable/available on a public network?

To answer the stated question- if Alice doesn't arrive at a hotel until a week after Bob has left- or, really, if she arrives at the moment just after Bob finishes his sensitive business- then it is unlikely that whatever nefarious activities Alice undertakes- in the context of targeting guests- will compromise Bob.

Schneiers first law notwithstanding, it would be unusual for a hotel to be capturing and storing traffic, and it would also be unusual for Alice to target that particular repository of data, should even she know of its existence. People currently at the hotel are going to be much more interesting targets, as their presence offers more opportunities to enable them to be compromised.

Phishing in general is far and away the most common method of compromise, and most compromises that occur are, from the perspective of the attacker, simply opportunistic commercial transactions. Guests staying at a hotel can reveal a lot of information about themselves that can be employed to convince them to open an email with an appealing and seemingly trustworthy offer- one that perhaps even appears to have been sent directly from hotel staff. Not to belabor the metaphor but hotel ponds are well stocked.

Of course, sensitive information about Bob will be stored in the systems the hotel uses to conduct its business, which include software to store and manage payment data as well as guest contact information, preferences and any notes made about their stay by hotel staff. Should Alice target and compromise these systems then Bob's information would be exposed to her.

On the general topic of hotel hygiene- for all intents and purposes, internet services at a hotel are like other shared services like pools and restaurants- amenities targeted to a captive audience. Cleanliness, quality, and other attributes are not necessarily competitive requirements. Internet services are no different.

Hotels have also always drawn elements looking to take advantage of guests- who are unfamiliar with the area, who aren't staying long, who have schedules and logistical constraints that prevent them from following up on inconveniences, and who on vacation often have their guard down.

Of course, you are not likely to be robbed at a large hotel in a major US city, and you are similarly not likely to have your credentials stolen. But if you are inclined to take precautions, you are not crazy for doing so.

From a practical perspective:

If you have a sensitive service provider who for some reason does not require https, find another service provider
If you travel and frequently have to do business over public or hotel wifi, for email and other sensitive accounts find providers who support 2FA https://twofactorauth.org/
If you have to check credit card or bank accounts from a hotel and don't have 2FA and you are worried about it, prefer getting a network connection from your phone by tethering over using the hotel network, either wired or wireless. It likely doesn't make a difference in any specific case, but generally speaking cell data networks are more safe.
Tor and VPN are not better than https on the specific issue of protecting credentials. All of those tools protect the content of your communications. What Tor and VPN also do is prevent someone monitoring network traffic from knowing whom you engaged with in those communications. With https, someone watching network traffic can tell that you had a session with Bank of America that started at 2pm and lasted for 15 minutes, though they can't tell what credentials and other data you exchanged. With VPN, someone watching network traffic can only tell that you connected to your VPN provider at 2pm, not whom you communicated with over the VPN. Only your VPN provider knows that. And with Tor, outside of state actors, no one monitoring the network has any idea what you did.


Fuzzing: Quickly find the exact number of bytes

Maybe I am misunderstanding but usually overwriting too much is not a problem.

The common approach therefore is to overwrite more than necessary but using a specific pattern. Looking at what ends up in EIP and searching for it in the pattern will tell you the exact position of the data that ends up in EIP.

Exploitation tools usually have this for, example PEDA has the pattern functionality.


[Disclosure: I work for AgileBits, the makers of 1Password.]

To give credit where credit is due (comics rarely have citation footnotes), this scheme is called "Diceware" and should be credited to Arnold Reinhold, who described it in 1995.

What is absolutely crucial to the scheme is that words must be chosen from the list by a uniform random process. (Reinhold's scheme involved rolling dice.) Humans, particularly when trying to be clever in selecting passwords, are very much not random.

Capitalization and symbols (the actual question)

hashcat, as it stands today, isn't good at applying transformations (e.g., case changes) to guesses that are done by combining words (needed for Diceware=like systems). So in once sense, using a few symbols and mixed case for these sorts of password will really make things hard for hashcat. However, that would be a stupid reason to do something like that. After all, a week ago, just using a passphrase longer than 15 characters would stymy hashcat.

It is unwise to base a password selection policy on potentially transient idiosyncrasies of a particular cracking tool. It is important to realize that other password cracking tools, John the Ripper, for example did not have that 15 character limitation. And has we know, these idiosyncratic limitations do change.

Look only had how many guesses are needed

The Diceware list contains 7776 words (you get these through five rolls of a die or one roll of five dice), and so a password would be about 12.9 bits per word. So a five word Diceware password would be about 64 bits. If hashcat could check 300,000 per second then it would be about 1.5 million years to crack a five word diceware password. How many guesses per second hashcat can achieve (on the same hardware) depends enormously on how the password is hashed (straight hash, PBKDF2, scrypt ...).

The reason I'm picking 300,000 guesses per second in my example is because that is the number we get against a common form of the 1Password Master Password (PBKDF2-HMAC-SHA1 10000 rounds), which I wrote about back in April. There are more numbers in that article, along with links to other articles on using Diceware (including the article,  Toward Better Master Passwords that may have triggered revived interest in Diceware just prior to the XKCD comic, and advocates a modified Diceware system for the few strong passwords you need to remember.)

hashcat character limit

Hashcat's move from a 15 character limit to a 55 character limit only matters if you were specifically choosing a password greater than 15 characters to avoid being in the domain of something that hashcat could work on. I hope that nobody was doing that.

In that article I wrote back in April I studiously did not mention the 15 character limit (which I was fully aware of) for the simple reason that I wanted to offer pessimistic (from the defender's point of view) estimates of cracking time weren't relying on what I saw as temporary limitations.


How to learn IP range from inside company

There are certain companies that provide such information.
An easy way is to go to the following url and put the company name you want to get the adresses for into the search box:

http://bgp.he.net/

You will be presented with a list of ip addresses connected to the specified company if there are any.
The link leads to the "BGP Toolkit" of Hurricane Electric, a internet service provider. It the tool behind that link vanishes at one time you might find similar tools from other providers.


Does HSTS prevent packet capturing in Wireshark

Let's back up a bit because you are asking about details on the extreme ends of a technology stack and your question misses the mark and doesn't make sense.

Wireshark just captures packets, so you could replace "Wireshark" in your question with "packet captures"
TLS encrypts the HTTP payloads, so GET requests would be encrypted
packet captures could still happen, but they would be encrypted

So, would TLS prevent the contents of a GET request from being exposed? Yes.
What about Bettercap?

HSTS helps to ensure one cannot downgrade HTTPS to HTTP
One attack in Bettercap (or any other Man-in-the-Middle tool) is to try to downgrade HTTPS
HSTS would prevent this type of attack

But that's just one attack. Another, better, use of Bettercap is to replace the certificate of the server with its own and decrypt the client communication. HSTS will not be so useful against that.


Cookie + CSRF Token vs OAuth Token for Native Mobile Apps

Sure, why wouldn't it be? You just lose (a lot of) the flexibility that is included in the many use cases of OAuth, which I assume you do not need. In particular, if you only care about your own app, and not about delegating access to others and/or allowing users to login with other identity providers, then you are just fine with this set-up. That said, if you are going to upgrade in the future, upgrade to OpenID Connect, instead of 'pure OAuth'.

A couple of remarks:

You will likely need to store the authentication token (which you normally include in a cookie) in some local storage of the device, as cookies do not exist in native apps. So you might need some kind of 'translator' in your app which catches the 'set-cookie' command and stores its value in the local device storage. Likewise for the other way around.
CSRF attacks do not exist in real native apps. However, if you use the same endpoints for both browser and app, you'll likely need to keep using them.
Use HTTPS (and possibly HSTS and HPKP) to secure your tokens during transport.


Is it secure to use the same token as both refresh token and access token?

If you're in control of both the client and the server and you can ensure that both tokens are always transmitted securely, there is no drawback in using the same token for both.

Normally, the refresh token is the critical token to protect, as this allows indefinite access to the application. It is also easier to control which transports this is transmitted over. However, in your case if you can apply the same security to the access token then there is no extra risk in them being the same.

Also see this answer.


How to find out what vulnerabilities X product has had/has?

What is the most effective / best method for obtaining information in
  regards to what vulnerabilities X device has or has had?

Checking the vendor's security advisories page is always a good start, anything they know about will usually go on there. As an example, here is a link to the Cisco Security Advisories page.

  Is there anything else I can do short of checking the security advisories page?

Yes, there is. For example, any "major" vulnerabilities will be assigned a CVE these will also be very helpful in identifying whether or not a specific product has X vulnerability or not. A good resource for this is CVE Details

  What if there is no security advisory page where else can I go?

If there isn't a security advisory on the vendor page then a few things could be applicable.

The vendor doesn't yet know if they are affected.
They're not aware of the vulnerability.
They aren't affected.

What should you do in this scenario? A good idea would be to contact the Vendors support teams. Going back to the Cisco example you could use Cisco TAC. This would be applicable to all vendors, if there is no public information on the device in question your best chance is to contact their support teams and find out.

If they are not aware of the vulnerability it would be a good idea to inform them of the issue, especially if you found it whilst doing some digging and it appears obscure. If you cannot find any resources from the vendor themselves (whether they know about it or not) inform them, I can almost safely say it will help. In the Cisco example, you could contact Product Security Incident Response Team

  What are some good resources I can use to find such vulnerabilities?

There are a lot of websites you can use other than the ones mentioned, the two below might also be helpful as mentioned by @Elsadek.

SecurityFocus
ExploitDB

You could also use CVE checkers as mentioned by @Forest.

CVECheck-Tool
CVEChecker

Another idea might be to subscribe to a security mailing list like the one below originally mentioned by @Forest.

Open Source Security Mailing List

This specifically is quite generalised however there are ones you could use which are more specific, as I mentioned earlier you could subscribe to Ciscos for example.


How hackers hide their identity while hacking?

You can do a lot of things to hide your public IP address. You can:

Purchase a VPN or VPS (preferably in bitcoin)
Route your traffic through the tor network
Use a proxy service

These are all well and good, but often, tor nodes and VPN IP addresses are flagged and banned from accessing some sites and services. In this case, you can:

Hack a website and use that server to launch an attack
Buy an "RDP session" to a residential network on the dark net


How does checking CRLs make sites less safe?

The unique problem induced by hard-fail certificate is that it introduces an additional choke-point outside the control of the site owner but in the critical path for site function, one which typically is not particularly well-resourced.

Since all secure sites require TLS certificates, and since most certificates are issued by one of only a small number of CAs, these CAs would represent a highly attractive target for people interested in causing disruption. And furthermore, these CAs are in almost all cases particularly ill-equipped to fend off an advanced denial-of-service attack, especially as compared to the sites they protect.

As long as most people leave hard-fail CRL/OCSP verification disabled, the CAs will not be targeted because the damage of such an attack would be minimal. But if strict verification ever becomes the default in a browser, then an attack against Verisign or RapidSSL or Comodo could take out entire swaths of secure hosts, doing vast amounts of damage.

Denial-of-service attacks are often used to mask or enable a more advanced and targeted attack. But in the case examined here, the true target of such an attack may never be known. The collateral damage would be so vast that tracking down a single victim would be impossible. It would be like shutting down the power to an entire city in order to rob a single jewelry store. But if the power company is an easier target than the jewelry store, then such an attack would be plausible.

As another analogy, if verification was the default, then taking down DigiCert's or Verisign's online verification service would be a lot like taking down the entire .com DNS registry. Many companies depend on it, and protecting it is outside their realm of influence.

Right now, for example, DigiCert is the CA used by Facebook. And while Facebook has multiple datacenters scattered throughout the world, DigiCert does not. Facebook has the resources to withstand an attack larger than anything anyone has ever seen. But DigiCert does not. If hard-fail certificate verification were the default, then an attacker needn't attack Facebook to be successful, he would only need to take down DigiCert.


Why is it more secure to use intermediate CA certificates?

Yes, the number of compromised certificates are much larger with Root Certificate compromise. But it's not just the number certificates. Getting a new root certificates deployed due to compromised root is massively more difficult than replacing the certificates whose intermediates are compromised.

For starters, replacing Root Certificate of a public CA, even in normal scenario, involves lots of paperwork and audits. In the scenario of a compromised root, the CA need to convince software vendors (browsers and OS) to readd their new Root Certificate to the default trust store. In the fall out of a leak, the CA pretty much lost all the trust that had been built over the years, and vendors would rightly be skeptical about the capability of the CA and the viability of the CA's business going forward. At the very least, vendors would demand reauditing and lots of additional paperworks before allowing the new Root Certificate Authority.

Vendors then would need to deploy the new trusted Certificate. This is extremely hard to do in a short time. People don't upgrade their browser often enough. Some softwares like browsers have mechanism to quickly broadcasts revoked root certificates, and some software vendors have processes to rush release when a critical security vulnerability is found in their product, however you could be almost sure that they would not necessarily consider adding a new Root to warrant a rush update. Nor would people rush to update their software to get the new Root.

These are in addition to having to resign and reissue the certificates.

There were a number of Intermediate certificate compromises (e.g. Comodo) where the CA quickly handled the situation and leave without any major consequences. The closest we have ever got to root certificates compromise of a public CA, is DigiNotar. DigiNotar went bankrupt in the following weeks after the compromise was made public.


How do ISPs detect whether a phone uses tethering?

I'm trying to figure out how ISPs detect whether a phone uses tethering beyond checking whether the TTL is set to a particular value.

There is a good description about various ways over at android.stackexchange.com - How can phone companies detect tethering (incl. Wifi hotspot). No need to repeat it all here but apart from TTL and OS stack fingerprinting it is also about the tethering feature of the phone actually telling the mobile ISP that tethering is active. For the latter aspect see also this post at Hacker News where it states that another DUN is used for tethering and how to avoid this.

Very interesting is also an article from Sandvine Policy Control for Connected and Tethered Devices since Sandvine is actually a provider for the necessary technology. In this articles it mentions features like TCP timestamp option, behavior of TCP source port, number of parallel sessions, various features from the HTTP request etc to distinguish different devices.

Similar Cisco offers tethering detection in its products as can be seen from ECS Administration Guide. Here it again mentions TTL but also OS fingerprinting and User-Agent detection.

  Also, do any major ISPs use a form of passive traffic fingerprinting?

This is very common. If an ISP offers pricing models where specific traffic (like some music or video streaming) is excluded from the accounted bandwidth then you know for sure that deep packet inspection is used. Apart from that it might be used to block or disrupt services which impact the business model or terms of service, like using VoIP or P2P file sharing or tethering. Sometimes it is done for legal reasons like blocking access to specific domains. But it might also be done to actually enhance the service, i.e. prioritize real time traffic against other traffic.


Network scan for vulnerabilities free tool

OpenVAS is very much like NESSUS except that the vulnerability feed at the heart of the service is free.  Tenable security gives away the NESSUS tool freely, but charges for vulnerability updates.

Based on  your description of the problem, you can also use NMAP scripts (check out this article) to list service ciphers:

  nmap -sV -sC target

  443/tcp open   https   syn-ack
  | sslv2:
  |   SSLv2 supported
  |   ciphers:
  |     SSL2_DES_192_EDE3_CBC_WITH_MD5
  |     SSL2_IDEA_128_CBC_WITH_MD5
  |     SSL2_RC2_128_CBC_WITH_MD5
  |     SSL2_RC4_128_WITH_MD5
  |     SSL2_DES_64_CBC_WITH_MD5
  |     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
  |_    SSL2_RC4_128_EXPORT40_WITH_MD5


What is going on with people trying to open Paypal accounts under my domain

This is what we call as standard Internet background noise. It manifests itself in different ways on different types of systems (webservers, mail servers, routers, VPN concentrators, etc..

It's just hackers using bots to get through points of low resistance. They're not worried about high failure rates because cost is low and payouts are well worth it. I know this sounds like normalization of something evil - it probably is, but the risk is low and cost of defense (beyond standard / minimal best practices) is high - so not quite worth paying much attention.

Now that you know the type of attack, do setup alerts - not for the failures, but for a success after a string of failures.

If you have a reputation system, you could also add any metadata you have about the attempt - for future tracking of potentially legitimate access from the same/similar source. Most reputation systems are IP address based - a technique that is low-fidelity in this day and age. So try to go beyond that if your logs have more info.


Does the e-mail send from an id to the same id requires encryption and other security checks?

It depends. If you address a snail mail letter to yourself (i.e. same sender and recipient) and put it into a public letterbox than its probably better to close the envelope (i.e. protect the letter). If you instead live alone and leave the letter to you on your own kitchen table, then protection is likely not needed.
If you send a mail to yourself using the GMail web interface then there is likely no "normal" mail transport (i.e. SMTP) involved at all. This means anything like SPF, DKIM, DMARC and SMTP encryption play are irrelevant and you will not find any traces of it. Even if you directly connect with authenticated SMTP to Google's mail server to deliver the mail, SPF, DKIM and DMARC are not relevant. These are only relevant when delivery origins from some external mail infrastructure outside of Google.


How to avoid password TCP message sniffing and subsequent hijacking

You could use a challenge-response mechanism. The server sends a random string, the client signs that using the private key. Since the server sends a new challenge every time, a replay attack won't work.

Or just use TLS to properly encrypt the connection. You could even use client certificates to replace your AES-encrypted secret password. TLS can provide both encryption and authentication, which seems to be what you are looking for. And another advantage is that you have to do a minimum amount of cryptography yourself, reducing the chance of implementation mistakes.


Is a concatenation of random numbers better than a single random number?

So is the concatenated random number better than a single random number?

If the random generator really produces random data then it will not matter.

  ... it would be harder to predict the next number in case there was an issue with the random number generator.

If the issue is that the random generator is not that random at all then it might even be better for an attacker to get as much last outputs as possible because then the behavior could be better to predict. Of course this assumption depends highly on the internals of the random generator, so no general answer is possible.

But in general: if you need really good random data you should use a proper random generator. Your method will not improve the quality of the output if the random generator is bad, i.e it stays predictable. If you actually don't need true random data but only want to make sure that you get somewhat random data without a bias you should be careful because depending on how exactly you do it your method might add a bias to the output.


To understand self-signed certificate, at first we need to understand the role of Certificate Authority(CA). I will explain things in the context of web servers
and browsers.

The role of Certificate Authority(CA) in HTTPS:

HTTPS employs Public-key cryptography which uses a key pair to encrypt and decrypt content. The key pair consists of one public and one private key that are mathematically related. A web server who intends to communicate securely with browsers can distribute the public key  but must keep the private key secret.

Now the problem is browsers cannot know with certainty that the key a web server used for encryption actually belonged to the web server. It is possible that another party monitoring the communication channel between the web server and the browser substituted a different key.
Certificate Authority(CA)  concept has evolved to help address this problem. Certificate Authority(CA)  is a trusted third party  which establishes the integrity and ownership of a public key. CA does it by signing the certificate (the public key of the web server) by using its private key. The browsers have built in public keys of well-known CAs and uses these to verify the certificates.

Self-signed certificate:

In case of  self-signed certificate, the webserver signs its own certificate instead of getting it signed by a third party CA. In other words, the webserver itself works as a CA for itself. OpenSSL can be used to generate self-signed certificate.

In case of self-signed certificates, browsers(e.g. Chrome) would not be able to verify the certificate, therefore it will complain.  To solve the problem, you can install the certificate of the self-signed CA in browsers.

References:

Wikipedia

Microsoft MSDN


In what way is a partially encrypted webpage insecure?

Let's examine each case from the perspective of an active attacker Malroy and a passive attacker Eve.

Case 1: An insecure page loading a secure iframe to transmit confidential data

Passive: You're secure against passive attacks while you use the secure iframe. However, in the case of log-in iframes, if your session token is ever sent in the clear, Eve can impersonate you. (I still count impersonation as "passive" here, since Eve is not actively tampering with your connection; she's just making her own connections with new information she learned.)

Active: If the HTML page itself is insecure, you've already totally lost. You can have every subresource on the page be securely transmitted, but it doesn't matter: Malroy has already rewritten your page to use totally different resources.

Case 2: A secure page loading an insecure page via an iframe

Passive: Obvious major problem here: anything you do in the iframe is in plain view. However, Eve can't see what you do in the top-level secure page. Still, the user is left confused about what elements on the page can be interacted with securely and which can't.

Active: Malroy can make anything appear in the iframe; I hope you weren't using it for anything important. I don't think there's any way for Malroy to break out of the iframe and read or alter your outer secure page, because browsers already assume cross-origin iframes are not trustworthy. If there were a way to break out of the iframe, I think it would be considered a serious security bug in your browser (which isn't to say those don't exist, but that's an implementation problem, not a theoretical issue with mixed content).

Case 3: A secure page linking to insecure JS

Passive: Eve can learn what HTTPS site you are viewing, based on what HTTP resources you load. (Granted, she might be able to do this over a secure connection, based on destination IP address and size/pattern of the encrypted resources you fetch. Regardless, HTTP only makes things easier for her.)

Active: As you guessed, Malroy can make your HTTPS page completely rewrite itself by feeding it an altered script.

Case 4: A secure page linking to insecure sources like images, CSS

Passive: Same as case 3, above.

Active: CSS is pretty powerful. If Malroy could rewrite a CSS resource, he could do some pretty heavy presentation manipulation. As an example, perhaps Malroy re-styles a the inputs fields of a forum's "Create New Thread" page to look like a log-in page. This tricks the user into thinking his session has timed out, and he unwitting submits his credentials as a public new post.

An active attacker could also use CSS to prompt a client to participate in a CSRF attack, e.g., by using background-image: url(http://www.bigbank.com/transfer?amt=1000000&to=malroy).


Does TLS authentication encrypt username as well as password?

If I'm reading your question correctly, you're connecting to your VPN using a combination of TLS client authentication and username / password combination.

In this case a MitM attacker can read the full contents of the client certificate (link to the relevant message in the handshake protocol), which may include your username. The attacker can not read the username / password combination because they're sent after the TLS handshake is completed and thereby encrypted.

The mitigation is simple on the protocol level: Don't make a mutually authenticated connection to the server outright, but a unilaterally authenticated one and then let the server initiate a renegotiation with client authentication. This is different, because the conection will be encrypted using the cipher suite from the first connection and so an attacker can't eavesdrop on your client certificate.

If this mitigation isn't possible for whatever reason, you can try and make the two user names unique and distinct. For example you could assign the user a fully random common name in the certificate, which is checked in the internal database / access control list to a) be allowed access and b) match the readable / human-chosen password. This way an attacker can not learn the user name needed for the username / password pair. As far as I can tell, such a setup is possible with OpenVPN.


How to determine which security testing method to use if resources are limited

It is important to understand that security assessment methods can use either black-box or white-box methods, and can be based upon either automated or manual methods.  All 4 combinations are possible (e.g., automated black-box pentesting tools; manual black-box pentesting; automated source code scanners; manual source code review).  Also, it is important to understand the difference between a security architecture review (looking for architectural/design issues) and a code assessment (looking for implementation bugs); usually, black-box and automated methods are mostly focused on the latter.  I'm going to assume you are focused on a code assessment, looking for implementation bugs.

With that background, here's a suggested checklist to help you decide which method to use:

Do you have source code?  If no, use black-box testing.  White-box methods require source code.
Have you ever done any kind of security testing, pen testing, security code audit, or other security assessment before?  If no, use black-box testing.  It is cheaper.  Start small and work your way up.
Are you just in it to comply with a mandate, or are you trying to protect your own systems?  If this is just about compliance, choose whatever the cheapest answer that will get you to the checkbox (typically black-box testing).
If you've made it to here, you'll need to do a cost-benefit analysis.    I would suggest starting with the cheapest methods, use them to improve your security software development lifecycle.  Then start by gradually easing into white-box and manual methods, and evaluate the value to your business.

Generally speaking, black-box testing is cheaper than white-box methods, but black-box testing finds fewer bugs.  Generally speaking, automated tools are cheaper than manual methods, they scale a lot better to large codebases, and they are better-suited to periodic scans/reviews, but automated tools may find fewer bugs than manual methods.

See also White-box vs. Black-box, Do blackbox penetration tests make sense if a whitebox audit would be possible as well?, Expected cost and time frame for black box pen testing?, How much does a security audit cost?.  Don't forget to try using search before posting a new question -- there's lots of good stuff already on this site!


Isn't OpenID over HTTP (not HTTPS) fatally flawed when delegates are used?

Yes, it is. So you should always use https.
Even worse, some service providers violate the specification:

11.5.2.  HTTP and HTTPS URL Identifiers
Relying Parties MUST differentiate between URL Identifiers that have different schemes.

Any consumer/service provider which violates this rule, is vulnerable to an attack. This is especially bad because a user cannot protect himself: He may use https every single time, but the attacker can just use http.
Furthermore a man in the middle vector is not required. It is sufficient for the attacker to be able to read the traffic to the identity provider; at a time of his choice.

When end user input is processed into a URL, it is processed into a HTTP URL.

So the behavior of StackExchange is in compliance as far as defaulting to http is concerned.
The specification continues:

[...] it is RECOMMENDED that a redirect be issued from the HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs are not equivalent and the Identifier that is used is the URL after following redirects, there is no foreseen reduction in security when using this scheme.
If an attacker could gain control of the HTTP URL, it would have no effect on the HTTPS URL, since the HTTP URL is not ever used as an Identifier except to initiate the discovery process.

Note: This approach is still vulnerable on the very first discovery process.
Specification: http://openid.net/specs/openid-authentication-2_0.html#anchor45


New CVE-2018-5407 "PortSmash vulnerablity" in Intel CPU

As with a lot of breaking-news coverage of computer security, there's a lot of questionable reporting on PortSmash. It's not actually very interesting, as it doesn't really add much to the attacker toolkit. It only affects a very narrow set of targets, which are already vulnerable to other attacks (and have been for years).

Colin Percival actually described the attack in question 13 years ago. The scope, specifically, is where there's a secret held in memory (a cryptographic key, for example) that alters what code your program executes. As Percival says in the linked tweets:

  The defence against PortSmash is exactly the same as the defence against microarchitectural side channel attacks from 2005: Make sure that the cryptographic key you're using does not affect the sequence of instructions or memory accesses performed by your code.

  So this story can be filed under "confirming what we already knew".  It's great work -- and I'm glad that after 13 years someone has finally gotten around to writing the exploit -- but it's not something users need to worry about at all.

So PortSmash isn't really anything that new; it's a small evolution in a class of side-channel attacks that all hyper-threading processors are vulnerable to, and have been since the beginning. And yes, it almost certainly impacts both AMD and Intel processors — as it may any hyper-threading processor where similar multi-threading features (specifically, ports or pipes — see comments on this answer for more information) can be maliciously abused.


Is wiping memory at code/end good practise?

If you wipe sensitive information early, you might arguably reduce the time window for an exploit while your program is running, but in general (and in particular in a when-process-exits context) it's a pretty useless endeavor.

It's much more important to lock memory that contains sensitive data, so it cannot be swapped out. Sensitive data being swapped out is something you want to avoid at all cost.
The worst thing about a page with sensitive data being swapped out is, by the way, not even the fact that it's written to disk, but the fact that you cannot guarantee that it will ever be deleted from disk again (due to drives doing wear-levelling). This is totally out of control of the operating system, or even your application.

Memory pages are zeroed before being handed to a new process on every non-joke operating system, so zeroing them manually does not really add anything (not on a realistic threat model, anyway).
Of course someone might use a DMA exploit (such as Firewire) to read physical RAM pages that have not been cleared, but they could already do that while your program is running, insofar not much is gained by erasing them a little earlier.


There are two strong options:

Strong password requirements. This negates the problem, by forcing the user to use a strong password. It will, however, reduce conversion rates if people get frustrated.
Single sign-on. This involves using a 3rd party service (e.g. Facebook, Twitter, Google, OpenID, etc.) as a login service, meaning you don't actually need to create a new account.

Since the competition is being ran from Facebook, I think a single sign-on is the best choice.

However, please make sure that you're requesting the absolute minimum number of privileges necessary from the user's account. Whenever I use an app that wants to use my Twitter or Facebook account, and it says "Can post Tweets for you" or "Can see your liked pages" when all I want to do is post a comment, I don't bother. It's an unnecessary intrusion.


Using AES with same salt / IV - required for pattern matching algorithm

If I understand your question correctly, someone may know some plaintext corresponding to the cryptotext and you are worried that this may weaken your key.

If so, AES is not susceptible to known-plaintext attacks. It means that knowing the plaintext corresponding to the cryptotext does not help to guess the encryption key.

You just need to have a good enough key, MD5 is 128 bits so it will take forever (which is an approximation of "(much)^(much) longer than the lifecycle of the encrypted information")


Certficate pinning: should I pin the leaf or intermediate?

You can pin leaf, intermediate CA, or root CA. All will work, but each comes with a usability / security tradeoff depending on the details of your setup.
The article you link actually gives a fairly good run-down of the differences:

Leaf certificate. By pinning against your leaf certificate you are guaranteeing with close to 100% certainty that this is your certificate and thus the chain is valid. Leaf certificates tend to have a short expiry time and if, for instance, the SSL certificates are re-issued because the private key is compromised your app will be bricked until you can push an update out. Of course the same may also be true if you frequently cycle your certificates.
Intermediate certificate. By pinning against the intermediate certificate you are trusting that intermediate certificate authority to not mis-issue a certificate for your server(s). This also has the advantage that as long as you stick to the same certificate provider then any changes to your leaf certificates will work without having to update your app.
Root certificate. By pinning against the root certificate you are trusting the root certificate authority as well as any intermediaries they trust not to mis-issue certificates. Often the root and intermediate authorities are the same company in which case there’s not much difference in the number of people you are trusting, however that’s not always the case.

In addition to what the article mentions, I'll say that then you pin a cert, you are removing the CA's ability to revoke that cert because your app trusts that cert implicely and will never go looking for status info for it. By that logic, pinning a CA (intermediate or root) has the advantage that when your leaf cert expires, gets hacked because you accidentally publish the private key on github, or whatever, you can easily ask the CA to revoke it and issue you a new one. Your app will keep working.
Personally, I would avoid pinning a leaf because you're essentially removing the parts that make a cert a cert: revocation and chaining to a trust root. You might as well do openssl genrsa and pin the public key in your app because you're not really getting any benefit from it being a cert.
That said, when you pin a CA, your app will trust any certificate issued by that CA, possibly to other people. You may be ok with that, maybe because it's your private corporate CA, or you may need to implement extra certificate validation logic to ensure that the cert chains to a pinned CA and the name matches what your app expects (and convince yourself that the CA would never in good faith issue a cert with that name to anyone who isn't you).

Summary: Pinning the leaf, intermediate CA, or root CA are all acceptable practice with some slight pros and cons. Do whatever makes sense for your app.


Why do major sites (eBay, Github) not ask for a password when I attempt to change email addresses?

Actually, github will ask you for a password when you attempt to change your email address. However, it does not ask if you are already in sudo mode.


Hash password with bcrypt before encrypting document with openpgp

I'll then generate a key pair with openPGP for encrypting the document. I'll encrypt the private key with a symmetric key generated from the password hash and I'll store the encrypted private key, encrypted document, and public key on my server.

Edit: I don't see a cryptographic weakness in this, however it seems very complicated for what you are trying to achieve. I'd suggest that you write down your exact requirements and then look for the most simple way in which your infrastructure and cryptography can fulfill them.

For example, I don't see a particular reason to use asymmetric encryption here (besides it being ridiculously slow compared to symmetric encryption).

  any concern [...] in generating two different hashes from the same password using two different salts.

No. Salt just "extends" the original data to make it harder for an attacker to use rainbow tables once they get your database. To my knowledge there is no attack, which allows (or makes easier) breaking the hash, if two hashes with different salts are provided.


Running SSH on a different port vs adding the port number to a password

A password with increased complexity is great, but if there is an exploit against the server software (OpenSSH or otherwise) that you're running, it won't help.  The idea behind an obscure high port number is that it won't be attacked in the first place, but there are caveats to consider:

High ports introduce an additional security risk.  If the SSH server goes down, a local user can stand up a new SSH server on the same port.  Only ports 1-1024 are restricted to the root user, so your alternate port should be in that range.  (This cuts both ways: port scanners only examine these ports, so you're less hidden.)

This is security through obscurity and should be considered "extra" but it should not be considered a part of the security when calculating entropy and risk.  It's not bad to be obscure, but it is bad to assume that obscurity provides sufficient security.  Adapting a quote from @barbecue:

  Obscurity is to security as camouflage is to armor.One makes it harder to find you, the other protects you once you have been found.

You might get fewer attacks on port 2938, but a weak password is a weak password.

I really like your idea of comparing the password entropy of whatever to whatever2938 (*changed from password and password2938 for reasons noted below), which I calculate to be 17 bits vs 30 bits, showing that the longer password is certainly more secure, but in order to model this properly, you'd have to get statistics on how many port-22-bound attackers would eventually break that longer password versus how many attackers that would both find the nonstandard port and break the shorter password, and even that analysis would have to assume the same rate of persistence even though attacks are increasing in both frequency and sophistication.

Instead, I'd recommend something like Fail2ban, which can recognize failed logins and ban the IP that attempted them (by default, Fail2ban blocks an IP for ten minutes after ten failed logins within ten minutes, but this is all configurable).  This limits attacks to trying one password a minute, so whatever would take about a week to break and even a more typical (yet still weak) password like Da5id would take 12+ years (222.6 ÷ 365 ÷ 24 ÷ 60 = 12) of non-stop password checking, which is presumably enough time to get you to notice the attempts in the logs.

Do not think that this makes weak passwords like Da5idRox a good idea.  Fail2ban only runs on the SSH server; somebody with shell access would break this in two weeks.

Of course, there's nothing stopping you from doing it all.  Add complexity to your password, use an alternate port, and block IPs with too many failures.  An additional obfuscation technique you could try is port knocking, which can even be done securely if the knock itself is encrypted end-to-end or uses a one-time password.

* A minor note: I changed the question's sample passwords to use whatever rather than password because password is a special case.  Common passwords like password (and simple variations) are best assumed to an entropy around 0–5, so e.g. p455w0rDz has an entropy of around 12, which is weaker than L%.  In the above math, I've instead assumed you meant a random dictionary word, which has an entropy of 17 bits). More on password complexity calculations.


You shouldn't be worried about it. It looks as if Teredo is a IPv6 tunneling technology. According to this Wikipedia article it allows for IPv6 connectivity by tunneling IPv6 packets through your router encapsulated in IPv4/UDP datagrams (so you can still talk IPv6 even though your router doesn't).


If your server resides in EC2, you can use IAM to create a role for that server and allow it access to KMS without needing to have the AWS access keys on the server.

http://docs.aws.amazon.com/kms/latest/developerguide/control-access.html


Connection between "Security Requirements Engineering", "Risk Analysis" and "Threat Modeling"

A lot of confusing terms and language here. For correct information risk language, please consider FAIR, or Factor Analysis of Information Risk

The terminology "Threat modeling" was correctly replaced by Cigital with the term "Architectural Risk Analysis". Using `threat' here is especially incorrect.

Risk assessment (e.g., OCTAVE, OCTAVE Allegro) is also very different from Risk analysis. A risk assessment is a documented, point-in-time questionnaire at best. A risk analysis can be much more useful when the input variables are selected and formulated correctly. By "useful", I mean that they reflect reality closer to what a human can correlate and fit to normalized patterns.

Without invoking the book, "Software Security Engineering: A Guide for Project Managers", I can tell you that security requirements engineering, as you request, is not a clearly-defined problem to solve in cyber risk. Many document-heavy projects based on Waterfall or other lifecycle prescriptions were abandoned in Information Technology and Application Development circles in the late 1990s. Today, our practices and value chains are aligned towards Scrumban, the most-modern evolution of xp.

If you can follow the FAIR model, then you'll understand how information risk will fit into your organization. This exists outside of your business processes -- it's a standard language to communicate with the multitude of players who could show up to the cyber risk conversation. Threats, as in TCom and TCaps, are an important piece of the FAIR model, so you must quantify threats in order to quantify risk. You must also understand the business. If you identify a vulnerability, or a control-set issue, then you will want to elicit root cause. Root cause is never a patch -- it's always back to the business process, typically consequence management or even crisis management.

If you want to see how you can truly fit these pieces together, I suggest you do check out FAIR, but integration is key -- and OpenSAMM makes that integration cleaner than anything else I've seen. If you need a strategic map to forecast your future outputs (or collect the right input variables in the first place), then OWASP OpenSAMM can be fit to any cyber risk need. You'll see the correct language around "security requirements engineering", "threat assessment" (your risk analysis), "design review" (your threat modeling), and much more explicitly defined and explained within.


Is the PGP Web of Trust / Keyserver infrastructure permanently broken?

Yes, it is broken, if you're

confusing the different kinds of trust (nice article, sadly the page is offline, but archive.org has it),
using it wrong (eg., just fetching any keys as described in your question) or
want to make others use it without educating them.

The basic idea is totally fine, but you have to be somewhat picky whom to trust (a.k.a. the Vouch, see link above). The concepts behind OpenPGP are rather complicated, and have to be applied with care.

Trusting others is a difficult job, and other trust systems aren't any better - the problem is just a little bit different.

Being specific to a single point:

  As an example, it's easy for someone to show up at a key signing party with a fake ID.

This is only a problem, if you arbitrarily trust anybody. Also: There might (and probably always will) be some people who wouldn't realize when somebody brings tampered documents. But with the amount of people joining the party, chances increase somebody will realize. And if someone does, he will be very clear on that. Brining a fake ID card to a key signing event is brave, I'd probably rather go for individual key signings to do so.


How are shopkeepers getting the MAC address of wifi enabled smartphones?

Most WiFi enabled devices broadcast their Mac address when probing for networks to join in the vicinity.

By placing your own WiFi device in promiscuous/listening mode and utilizing a tool like Aircrack-ng, you can see and record all broadcast traffic enabling you to see if a device with a specific MAC address comes within earshot of your listening device.

See: Is your smartphone broadcasting your movements when you shop?


Is it "cross-platform attack" if first OS is not attacked at all?

The scenario you describe qualifies as a cross-platform attack simply by the fact that one device attacks another.

The mobile app containing worms may not harm the mobile device itself, but it is by any other name a malicious, infected device. When plugged into the PC, it launches the attack to that platform, thus making it a cross-platform attack.

A specific example can be found on the TrendMicro antivirus website here.

That page describes the method of attack used by the TROJ_DROIDPACK.A trojan, which does exactly what you have asked about in your question, and is referred to as a cross-platform attack.


How has someone gained access to the password for my Google account?

There were dozen possibilities for the compromise, Let me say the possible exploitation where hacker might got your password :
1)You might be reusing the same password again :
You might be having the password which was reused from any of the breached accounts, Inorder to check whether your account comes under breach you can check under sites like haveibeenpwned.There were sites like databases.today which provide breached database information too.
2)You might be victim of keylogger or any spy programs :
You might have copied a song/movie/software to a friend through USB drive and your friend might possibly sent keylogger or copied passwords along with it.
3)You might be used your gmail in open wifi hotspot :
This is the worst case of you being targetted , You might be signing in open wifi hotspot where your password might be sniffed.
4)You might be using weak password/your security question might be very easy to crack
5)you might be shoulder-surfed.
Now let's see what we can do next :

Never repeat passwords
Enable two step authentication for your gmail account
Clear all active sessions in your account
Check for apps which has authorization and remove it[privacy check of google does it]
Always have a habit of scanning pendrive before copying using antivirus scanners which is maintained uptodate
Never use weak passwords and have a  eye over the security questions which you have set
Never signin at open wifi hotspots.


Combining MAC and encryption is hard. Depending on how you do it, the result will be secure, or not, or only "mostly secure" modulo a zillion of implementation details. GCM is an Authenticated Encryption mode which does all the hard work for you, so it is warmly recommended that you use GCM (or an equivalent mode like EAX) instead of designing your own protocol.

For research purposes only, the MAC value will be part of the encrypted data if you use MAC-then-encrypt, whereas it will have to be transmitted or stored separately if you use encrypt-then-MAC or encrypt-and-MAC. Afterwards this is only a matter of encoding. "Encrypt-then-MAC" is recommended notably because since the MAC operates over the encrypted data, it cannot reveal anything about the plaintext data, so the MAC value can be shown to everybody with no ill effect.


The technical reason is to keep CRL size under control: CRL list the serial numbers of revoked certificates, but only for certificates which would otherwise be still valid, and in particular not expired. Without an end-of-validity period, revoked certificates would accumulate indefinitely, leading to huge CRL over time.

However, since network bandwidth keeps on increasing, and since modern revocation uses OCSP which does not suffer from such inflation, this technical reason is not the main drive behind certificate expiration. In reality, certificates expire due to the following:

Inertia: we set expiration dates because we have always set expiration dates. Traditions, in information security, often lead to dogma: when security is involved, people feel very inhibited when it comes to changing long-standing habits, in particular when they don't understand why the habit is long-standing in the first place.
Mistrust: ideally, certificate owner should seek a renewal when technological advances are such that their keys become inadequately weak (e.g. they had 768-bit RSA because it was fine back in 1996). But they don't. Expiry dates enforce renewals at predictable moments, allowing for gradual, proactive evolution.
Confusion: expiry dates can be viewed as a translation of housekeeping practices from earlier military cryptosystems, before the advent of the computer, where frequent key renewal was required to cope with the weakness of such systems. Some people think that certificate expiration somehow implements that practice (which is obsolete, but hey, Tradition is Tradition).
Interoperability: existing deployed implementations of X.509 expect certificates with an expiry date; the field is not optional. Moreover, some of these implementation will refuse dates beyond January 2038 (that's the year 2038 problem).
Greed: if you are a CA in the business of selling certificates, well, you really like it when people have to come buy a new one on a yearly basis.


How to get started in information security with sales background?

This was discussed recently here -> How do I get started with security? (beginner). There are some excellent answers there.

Additionally, Robin Wood has recently done some research on this topic and I think you will find it useful. He presented it at BSides London recently and has posted his findings on his blog - http://www.digininja.org/projects/breaking_in_part_1.php.

I also did a blog post with a friend (@securityninja) on something similar a few months ago - http://www.securityninja.co.uk/application-security/random-thoughts-on-education-learning-from-markofu/ - which you might find useful.


Disable SSLv3 in Dovecot --> TLS handshaking failed: no shared cipher?

The situation is I'm trying to disable SSLv3 in Dovecot by adding !SSLv3 to the ssl_cipher_list:

This is a bad idea because there are no ciphers specific for TLS1.0 and TLS1.1, that is they use the same ciphers as SSL 3.0. Only TLS1.2 defined some new ciphers. This means, that if you disable SSLv3 ciphers no SSLv3 clients can connect, but also no TLS1.0 or TLS1.1 clients. This is probably not what you intended to do.

The real way is not to disable the SSLv3 ciphers, but to disable the SSLv3 protocol, but I cannot see an option for it in Dovecot 2.0. According to https://zmap.io/sslv3/servers.html there is an ssl_protocols setting in Dovecot 2.1+, but the same page also wrongly recommends to disable SSLv3 ciphers in Dovecot 2 which is just wrong.


DNSSEC implementation questions (BIND 9.10)

1 (Same ZSK):
You should not use the same ZSK for multiple zones (as far as I know), as it is a zone signing key. There should be one ZSK for every zone.
2 (Journal Files):
You cannot move the journal files with the current version of bind, however you can make the zone files in the directory bind uses symlinks to files in a cleaner directory.


netcat reverseshell hanging after connection

I suggest that you try using either ncat or netcat instead of nc.
Plus Ncat support -e function for executing, and i do not think that nc does in the current version.


Can a VPN avoid the Prism Surveillance Programme?

There isn't really enough information out there to know exactly what is being collected, but if most of it is meta data in nature or user records from services, then a VPN isn't really relevant.

For the first situation (phone/Internet connection meta-data), the contents are not being requested, but only what connections are made.  While the contents of your IP traffic are protected by a VPN, unless a time delay is incorporated, it is fairly easy to match an incoming and outgoing packet based on timing in most cases.  Thus, it would likely still be completely possible for your VPN traffic to be traced without revealing the contents.

As for the access to user data, if you are putting information out there and it is associated with your account on one of the companies, there has never been reason to think that the government couldn't get it if they had a legitimate reason to need to and a VPN wouldn't help there at all.

The real question raised by the PRISM disclosure isn't so much if such mechanisms are possible (It's been very well known that it COULD be done and that in itself isn't news.)  The news is the scale at which they have been doing it and the question is if the government has a right to do so or not.


Directory traversal & default filesystem permissions (755) for web server

In terms of restricting what a webserver can do - I usually grant access to the content by the webserver via the 'other' entity (rw-rw-r-- / drwxrwsr-x) - this allows me to set up a group (in some cases multiple groups) of people who can maintain (write) the files. On a simple machine it also means I can strip execute and read permissions elsewhere minimal impact. But using chroot (or containers) is a more effective solution where applicable.

Your example code seem to be using PHP: disabling allow_url_include and setting open_basedir are essential first steps in hardening a server (there's lots more - but this is straying off-topic). Setting open_basedir prevents nearly all directory traversal mechanisms. But the really important thing is to not process paths supplied from the web unless you you cannot avoid the issue - and even then thoroughly validate the data using a whitelist and realpath().


On the Use of Deltas in Linux Entropy Estimators

The estimator uses minimum third delta because the degree of the fitted polynomial of it is the entropy of the dataset. In the first example, the minimum delta was 2, its base 2 log is 1, therefore the data overall added 1 bit of entropy. Why the minimum delta? It is because using it allows to represent the entropy (in other words, unpredictability) of the entire dataset as a one-digit number. If you look at the entropy measurements in the first two examples (1 and 2 bits), you can see that they translate to 1st delta values of about 10 and 100, respectively. Accordingly, entropy of 3 would mean 1st deltas of about 1,000, 4 - 10,000, and so forth. In summary, in our delta representation we went from multiple to single digits by using the polynomial degree of the minimum third delta.


Does embedding (concatenating) a user ID in a session token for logging have any security implications?

It can have potentially serious implications. If the user authentication process use that User ID, an attacker can do a DOS attack sending wrong authentications data and locking User ID account.

If the User ID is not directly consistent to user personal informations (e.g. anonymization)  it is not considered personal data.


Creditcard store first six digits PCI reference

Considering your questions indicate you are already processing card holder data, either by transfering PANs or storing (partial) PANs, you fall in the category of SAQ-D. So this means you should be already undergoing PCI audits (provided you have over 300k transactions annually), so best is to check with your QSA and see what they say.


How can I use phpinfo.php file to find new files on a server

As stated in @Matthew's comment, the PHPinfo file itself does not pose a direct vulnerability, nor does it have "common exploits".

However, an exposed PHPinfo page is considered to be an information disclosure vulnerability, and may reveal significant information about other components or configurations which actually may be vulnerable.

As you have mentioned, the page displays version information for PHP, the system, Apache, MySQL; perhaps an online search for the product and version number will reveal some potential next steps (e.g. a search for "PHP 5.4.16 vulnerabilities"). Make sure to investigate the same for any installed modules as well.

If you aren't able to find any vulnerable and exposed software this way, perhaps an issue exists somewhere else on the page, maybe in the configuration of something, but it is impossible for us to know without being able to see the whole page. Identifying the vulnerability may require some background knowledge of the system and the services it is running.

Finally, it is possible that the PHPinfo page is just a small hint or perhaps a red herring, and it may be more fruitful to spend time taking a different approach. But again, it really depends on the situation, and there's no way to know for sure given the information in the question.


Can anyone tell me at this platform that what is the difference between filtered ports and blocked ports?

Upon closing a port, nmap reports it "closed".
When it reports it "filtered" it means that it is behind a firewall or other security control so nmap cannot resolve the port and reports it filtered. It can be open behind the firewall but from your network, it is behaving as a closed one.


The only practical ways to do that are to use the same salt for hashing all passwords (bad) or to store the passwords in plain text or reversible encryption (very, extremely bad.)

Since those approaches are big and bigger security problems, I'd guess Google isn't doing either of them.  What they might be doing is disalllowing the 1,000 or so most common passwords.  There's a list of common passwords here: https://xato.net/passwords/more-top-worst-passwords/  (Note that if you disallow the top 10,000, for the "ordinary" user, you've disallowed everything.)

Edited to add: I guess you could store the last n passwords and their (different) salts.  Seems like a lot of trouble.


How Generate Custom Dictionary Password list

You could use a tool that expands regexes, such as exrex:

$ git clone https://github.com/asciimoo/exrex
$ cd exrex
$ python exrex.py '[pP][aA@][sS$][sS$][wW][oO0][rR][dD]'
password
passworD
passwoRd
passwoRD
passwOrd
passwOrD
passwORd
passwORD
passw0rd
…


Does PGP encrypt all messages or only that one send with PGP?

PGP only encrypts the emails you send out. Secondarily, you can decrypt PGP-encrypted emails if you have the sender's key.

Facebook and Dropbox do not send PGP-encrypted emails.


How are private keys (sMIME, PGP, etc) synchronized across a user's devices?

Typically private keys are not shared. You have a different key for every use, which typically includes every device. I'm not sure that's the right decision, but it's the typical one.

However, most private key storage technologies support encryption. They often say "password protection" but it's implemented as strong encryption. So in my opinion, as long as you "protect" with a suitably impossible-to-guess password, then the security is largely under control. I wouldn't put it up on pastebin simply because there's no need to invite unnecessary risk.

As an example, I have an SSH key that was used as the only point of access for a set of servers. That key was protected by a random password and was never stored unencrypted, ever. That encrypted key, along with other important files, was saved to a folder that was mounted using encfs, controlled by another random password. The backing-store for the encfs filesystem was a folder synchronized between workstations by Dropbox.

So to get at my key, you'd have to get in to my private Dropbox folder (non-trivial, but not impossible), guess my encfs password (significantly more difficult), and then guess my private key password.

For one person to get lucky enough to hit all three is unlikely enough for me to feel pretty confident in the syncing arrangement. And I get all the relevant important secret documents synced between all the associated machines across Linux, OSX, and Windows, and it just works. Each "secret" folder is only encfs-mounted on-demand when they're needed, so even though the files are technically present everywhere that Dropbox syncs (good for backup purposes), they're not available without the encfs password.


How safe is it if encrypted text is exposed?

If you are encrypting a client secret where it needs to be decrypted and used to access another service, you should not expose this to any untrusted system, including checking in to source control, as that would mean that people with access to the system would be able to get access to the secret.

Also other automated processes which work off the source code repository (for example code review tools) would get access, so you could end up with the secret being known quite widely which is rarely a good idea.

One way to approach managing this kind of secret is to store them separately during development and then inject them at deployment.


Why is Mother’s Maiden Name still used as a security question?

Because people are lazy and/or incompetent. And, well, you know, the Internet is full of chimpanzees.

I would argue that all security questions are bad, but using the mother's maiden name is exceptionally bad:

At least in Sweden, I can find out anyone's maiden name just with a simple call to the tax office. It is literally public information.
It's 2018, and fairly common for couples to adopt the bride's name when getting married. Your mothers maiden name is then your surname. Great.
Luis Casillas rightly adds:

  There are dozens of countries, with billions of inhabitants between them, where women don't change their legal name when they marry. The United States in particular has huge immigrant minorities of people from such countries.

Seriously, there are no excuses for this. It's just bad.


What are the exact security risks of having JavaScript enabled?

What serious security threats are there that solely rely on the client JavaScript code that the browser allows?

One risk are buggy implementations which can be used to crash the browser or execute code by using heap spraying attacks or similar. These can be kind of mitigated within modern browsers by using ASLR, DEP, sandboxes and similar techniques.

More interesting are attacks like Cross Site Scripting (XSS). These attacks can be used to steal authorization credentials (i.e. passwords) or hijack existing sessions. This way they can be used for identity theft or misuse. They work because the same browser is used for different web sites (i.e. banking and looking at cats) and this way it tears down security borders between these sites. Same Origin Policy is only of limited use in these cases.

A typical case of such attacks is the inclusion of third party scripts into a web site. This can be external Javascript libraries, tracking code like google analytics, buttons for social networks or advertisement. This included code is out of the control of the original web site but still has full access to the site inside the browser and can thus read information from it, fill in forms or read their content, navigate the user to different sites, press like buttons,  inject advertisements or malware etc.

Apart from that Javascript can be used to fingerprint the browser in a more detailed way which might be a problem especially when trying to be anonymous.

  Can information outside of the browser be accessed and sent off to the server?

It should not be possible to access files on the local machine (at least not without notification) but with attacks like DNS rebinding it can be possible to read the contents from intranet web sites and forward these information to the attacker.

Also bugs in local or intranet servers can be used to hijack connections to third party side like done in this example of same site scripting.

  Can files be downloaded to the client computer without the client's consent?

This can usually not be done with Javascript alone but is often done by using bugs in Flash or Java.


Base64-encoding processes input bytes by groups of 3; each group yields 4 characters. The '=' signs are padding so that the string length is always a multiple of 4; since the '=' signs are not part of the core Base64 alphabet (letters, digits, '+' and '/'), the decoder knows that these signs are padding and don't encode actual bytes. That way, input sequences of n bytes, where n is not a multiple of 3, can be unambiguously encoded and decoded back.

Entropy-wise, the '=' signs do not harm and do not help. You can leave them or remove them as you wish, it would not change anything for security.

(If they hurt, then this means that the password hashing function used in the system is extremely poor and weak, and that would be a problem which should be fixed -- not by removing the '=' signs, but by using a good password hashing function instead.)


Is there a name for an anti-virus station / kiosk?

A "sheep dip" station is one term - from the practice of dipping sheep in cleansing fluids before letting them near the rest of the flock.


The system that is verifying the certificate chain has a local store of root CA certificates. The private keys associated with these certificates are used to sign intermediate certificates. The private keys for the intermediaries are then used in turn to sign certificates that are issued to servers. When obtaining the certificate chain from a server (the full chain can be requested from a properly configured service) this chain is walked, verifying signatures up the chain, all the way to a root CA that is in the systems local store.

If an intermediary cert was forged then the signature from the root CA that signed it (contained in the intermediary cert) would be invalid and the chain would be broken.


A password of 13 alphanumeric characters CAN be robust enough to ensure security. There are 6213 such passwords, a number which is close to 277. If you choose such a password with full uniformity (i.e. you generate all 13 characters independently from each other, using a strong random source, i.e. /dev/urandom or some dice but not any biological brain), then you have 77 bits of entropy, and brute-forcing that is on the verge of the possible. That is, it could be done, but it would be expensive (cost in dollars would rise to the billions, not mere millions). In that sense, setting a 13-character password for your home WiFi should not impact your security too much, if you do it properly.

However...

A limitation to 13 characters screams of WEP. WPA and WPA2 can use any password length between 8 and 63 characters; a password length limited to 13 (a weird value in the absolute; developers prefer powers of 2) probably means that the thermostat will want to connect to your WiFi with WEP.

And that is bad news. WEP has a very poor design and can be easily broken through with software which is readily available for free, regardless of how random the password is. It is probable that even with the 13-character password, the thermostat won't connect until you configure your router to allow WEP, and that would punch a hole in your security. A big hole. Rather a four-lane tunnel, really.

It is relatively easy to check, though. Set a 13-character password but without enabling WEP, and see if the thermostat can work with that. But if you value your network security, do not enable WEP. Never.

(If you really must make this thermostat work and if that cannot be done without WEP, then you might consider buying an extra WiFi router, for the benefit of the thermostat alone. Then link that extra router to your network with a firewall in-between, blocking everything except that which is strictly necessary for the thermostat to do its work.)


Unix - Is it safe by default to give a new user ssh access and be certain they can not alter the system?

This depends on what the user can do with the SSH access. If he is limited to specific actions like scp/sftp, selected port forwarding or running selected commands the risk might be small. If instead the user has full shell access then he can use local privilege escalation attacks to elevate his privileges from a normal user to system user. Bugs which allow such attacks get regularly detected and some of these lurk for many years without getting publicly known and fixed.

Apart from such direct privilege escalations a user with shell access can also connect to network services which are explicitly restricted from outside access and might not be that well protected because of the risk is considered low. This might for example be local database installations with insecure and easily brute-forced passwords. And apart from the local systems the user might get access to internal systems on the same network which are usually protected from the outside using a firewall.

And of course a user with a login shell could just exhaust system resources like memory, CPU time, I/O or disk space unless specific limits are set on the account.

These are just the more obvious problems. But note that most of these could also already be done from inside a PHP script or similar server side code in control of the user.

In summary:  if there are sensitive data on the system or on connected and reachable systems don't provide a way for an untrusted user to execute arbitrary code as a non-privileged user. This involves shell access but might also already involve using its own PHP scripts or similar. If such code execution is needed you can try to mitigate the risk by adding additional security layers, like sandboxes, containers or similar but note that these restrictions are not unbreakable either.


Where can I report a program to be reviewed for security vulnerabilities and privacy issues?

Unfortunately, there is nowhere you can send software to be independently audited for free. While you can send a bug report to the authors as already mentioned, that will not result in a comprehensive audit. Software audits are complex and take a lot of time, which means they can be quite expensive.

If the software seems like it's not written well, or you suspect that there are likely other severe bugs hiding in there, the best thing to do would simply be to look for an alternative. This is especially important if the software is obscure or rarely used and is unlikely to attract a lot of reviewers.


Why can't a hacker just obtain a new SSL certificate for your website?

Being able to MitM a certificate authority is perhaps not as trivial as you imagine.  You don't know what machine they're using to evaluate ownership, and hopefully they aren't doing this over Starbucks wifi.

Certificates apply to domain names, not machines or IP addresses, and thus ownership is generally not verified by testing responses given by a certain HTTP server.  For instance, taking a look at Mozilla's requirements for CAs,

  We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:

  all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate;
  for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf;
  for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant’s behalf;
  for certificates to be used for and marked as Extended Validation, the CA complies with Guidelines for the Issuance and Management of Extended Validation Certificates version 1.4 or later.

So you would need to either MitM the connection between the CA and a DNS server, or compromise the site's DNS (the more likely one).


What happens inside of a DDoS Scrubbing Center?

At the scrubbing center there are multiple layers of protection through routers, different mitigation appliances and use of high capacity bandwidth links that distribute the traffic. The difference is, upon attack, this traffic is analyzed remotely. Generally this involves the victim to route their traffic via a BGP announcement to the mitigation service provider, requiring an ASN or making a DNS change to point the attacked domain to an IP address within the mitigation provider's network. Either method should require some baselining of normal traffic to help generate a profile and reduce collateral damage. Before choosing a provider, one should request a "stress test" to confirm the provider's mitigation abilities.


25% of attacks were perpetrated by internal attackers is what the Verizon Data Breach Investigations Report reports.

I cannot think of anytime that HTTPS should NOT be used.


Can I spoof my user agent so that the type of device I'm using doesn't show up?

Your device type is explicitly encoded in the user-agent string. Compare these UAs:

Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1
Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; SCH-I535 Build/KOT49H) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

In this example iPhone idicates, well, an iPhone, and SCH-I535 is the model number of a Galaxy S3. Consequently, if you change the UA to a custom string, most websites will identify you as a different device. However, there are also many advanced device fingerprinting techniques which are potentially less accurate but also harder to block.

  if I own a Mac, does using TOR along with a proxy protecting me from a website like Gmail finding the type of device I am using?

The Tor browser aims for a design that minimizes possibilites for device fingerprinting. However, it can't stop everything. For example, if you're running the browser in full-screen mode, you're giving away your device's screen resolution. You can read the Tor browser docs chapter on fingerprinting for an extensive list of what exact measures they take.


How can Draytek products not be affected by KRACK as they claim?

The Key Reinstallition AttaCK attacks the client - not the access point. As they state clients connecting to their devices can be affected.
*Further to @Darrens point this may not answer the question. Whilst the attack is based on re-transmitting a message to the client since the problem is in the protocol and both ends can detect the attack arguably both should be fixed.
**Reading further there appear to be additional attacks attacking the AP. Reading up further now. Its possible Draytech don't use these features.
From the main release page

What if there are no security updates for my router?
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details.

***Having re-read the entire release I can't see anything that suggests an attack targeting the AP directly. So I believe the view Draytek is taking is that since the attack is targeting clients the patch should be here. Whether that is the correct view is arguable either way.


how to access to arachni scanner web interface?

You've started a web server listening on port 9292, that's what the output says. Now you need to connect to it with a web client (browser) on that port. Try with http://localhost:9292, if you're accessing on the same computer you're running your server on, or replace localhost with the IP address on which the server is running (after making sure you're not firewalling selected port, in your case 9292).

Wiki of Arachni's Web User Interface


An attack from a remote location to fake your IP address, as opposed to just using your IP address, is very difficult to pull off as it requires changing the Internet network routing tables. Otherwise, the network packets would go back to your machine, rather than to the attacker's.

An attack from the same area might work if your Internet IP address is a dynamic one, as most home broadband ones are. They may be able to bump you off your IP address if they're using the same ISP in the same area by timing a renewal of their IP address just as your DHCP lease expires, before your router manages to re-acquire it, but it isn't easy to do. It would probably be easier to hack into your network to do it, or indeed, to take over your machine.


How can you be sure that there is a virus on your computer?

None of the symptoms you posted is a sign of having malware on your computer.

  My internet connection slows to a crawl often

Complain to your internet service provider or find a better one.

  my games keep crashing

Viruses don't tend to do that. When you have problems running games, it's far more likely to be a problem with your graphic driver... or just that you happen to play buggy games. But that's not a topic for this website. Gaming stackexchange might be able to help you with a specific problem.

  my Ubuntu server is sending things to a domain called "rubay.canonical.com"

Canonical is the company which makes Ubuntu, so there is nothing suspicious about that. Opening that domain in a web browser shows a directory listing with filenames which hint that it might have something to do with checking for updates. Ubuntu Stackexchange might give you a more profound answer when you are curious.