What a information security help desk looks like

What you are asking about is generally referred to as a Security Operations Center (SOC pronounced as "sock").  In this place Tier 1 security analysts review security incidents as they come in to determine if they are false positives or if they should be escalated to Tier 2 analysts/engineers.  If not a false positive they will generally write up a summary of the incident and escalate to tier 2.  Tier 2 will investigate and determine if the event is a false positive and or if it needs to be escalated to Incident Response (see below) or tier 3 for further analysis.  The exact breakdown of work between the tiers differs by organization but usually there are 3 tiers.  Some of this can be provided on-prem and some of it farmed out to a Managed Security Service Provider (MSSP).

The size of the organization and the maturity of their security team determines how the SOC looks (if they have one at all).  In some smaller/less mature organizations Security tasks are handled by the IT help/service desk.  The SOC is the preferred model and should involve plenty of overlap with the Network and IT/Admin teams as proper configuration by these teams is the backbone of security.

Furthermore in mature organizations there should be a separate incident response (IR) team which has business context and Administrative insight/access to hunt down and remediate any issues escalated by the SOC.

Additionally, or as part of the IR, team there should be a digital forensics team to escalate investigations that appear to be of a serious nature.

Finally there is a Huge Wealth of information on the web about this topic so look around and do plenty of reading.  You kind of only get one chance to build a SOC so build it right.


What do the various browser "private modes" do?

They are meant to clear a part of your browser history that is in this so called "private" session and to separate that session from previously existing sessions as well. Things in this session won't be stored after you leave the session.

This is not a 100% foolproof method however:

They will still be able to track you based on your IP-addresss and your screensize, System Fonts, Browser Plugin Details, etc (see: https://panopticlick.eff.org/ ) You just don't store browserhistory including the caches and cookies in your browser after you leave the "private session".
People will still be able to track you, when you are not careful enough with using your known usernames. Think about moderators, your so called "friends", but also people who forget to set their privacy settings on Youtube and Facebook for example. The default setting is that everyone can see what videos you watched and what you shared.

So it doesn't protect from human stupidness, like giving your "Lulzsec" hackerfriends all your personal information:
http://www.foxnews.com/scitech/2012/03/06/hacking-group-lulzsec-swept-up-by-law-enforcement/
So it doesn't work when you threating to blow up a school on twitter. No matter whether your "private modes" is enabled or not. http://www.ajc.com/news/student-arrested-for-threatening-1398649.html

It doesn't protect against geolocation data. For example when you forget to turn off geolocation, when tweeting an image that was originally taken with your mobilephone. Or when you accept to give your geolocation to a service like Google Maps.

So it doesn't protect from human stupidness like checking in to a location on Facebook, when you are on the run: http://www.abc15.com/dpp/news/region_southeast_valley/chandler/oregon-fugitive-caught-in-chandler-after-facebook-check-in

Is not a protection against viruses, keyloggers, screenloggers and other malware. And hacker who gains access to your the server or your credentials can still access some of your private information on sites you visited.
In the past there were some problems some cookies - like the Flash Super cookies -  still being able to track you in this private mode. This issue has been resolved since then. http://lifehacker.com/5470515/flash-finally-adds-support-for-private-browsing


Since you are going to use a script in a page (as opposed to redirecting to a payment page maintained by the service provider), you are subject to PCI-DSS A-EP requirements.

JavaScript is not explicitly mentioned there, but the general requirements you need to follow are (cryptographic measures for instance).

EDIT

Beside Conor's relevant comment below, a few comments on some of the
security points you mention in your question

  The script and the form that collect sensitive data must be hosted in
  the PSP domain and inserted in the merchant webpage with an iFrame.

It does not have to be inserted in an IFRAME, it can be injected as a script directly in the page (see for instance Stripe's API)

  The merchants website must load the script directly from our domain in
  order to remain PCI complaint (There is any way to check this point?).

This is their problem, not yours - you just provide the scripts and take responsibility for them.

  Javascript file must be minified and uglified.

This does not add any reliable security (the minification and uglification is done for performance, and maybe some kind of obfuscation which does not hurt but cannot be tagged as "security measure")

Please also note that the JS part of the code is inherently insecure, you must not rely on it for the security of your data (apart some few general points described in OWASP). The security you need mostly to worry about is on the server (backend) side. You should always assume that what you receive from your frontend is insecure.


Is it safe to load a forensic image which might contain malware?

It's somewhat safe to load on Autopsy, to dissect it using fwextract, lazarus, and with a bunch of forensics tools, but is not safe to execute anything of it nor open any files from it using the default applications.

It's easy to create a bunch of infected pdf files that will exploit your Adobe Reader, or png files, or whatever. Some files can infect your system if you run strings on it.

To be safe, use a VM to explore a infected system. It's easier to maintain, and you can clean up everything if you mess things up.


What does a switched network protect us from? What does it not protect us from?

Switches are not meant for security. A switch differs from a hub in that it observes packets to deduce where each host is, so that a packet aimed at a given host will be written only on the physical cable leading to that host. This is a performance optimization in that it allows more traffic to happen concurrently on a given network.

The side-effect of packets not being generally broadcasted (physically) on the whole network has been historically mistaken as a security feature. But there is no guarantee that a given packet will not be copied on unwanted links; the switch operates on its own knowledge of the network layout, which is backed by a necessarily limited amount of RAM within the switch (the "ARP cache"). By "spamming" the switch you can overflow the ARP cache, leading the switch to fallback to hub-like behaviour (incoming packets are copied on every link); you can also misinform the switch with fake ethernet packets (so-called "ARP cache poisoning"). These limitations demonstrate that switched networks are not secured networks, they are just optimized networks.


Allow a user to check if they are in a database, but reduce the risk of curious third parties checking

Contact Information present

You have their e-mail or phone number in your database ?

If so, send any information to that contact information and only display a generic "thank you, if you are registered with us you will receive a confirmation to your registered contact information" message on the website. This message is always the same no matter if the user is in the DB or not.

In fact, to thwart timing attacks you should display the message and exit, and do the lookup and sending of mail or SMS in a background batch process.

Rate limiting, etc. was already mentioned, definitely recommended.

No Contact Information

If I understood correctly, you also have users without any contact information. These guys are tricky. The problem is that name and DOB are not secret information in any way. For most people, it takes minutes to find them out, and any skilled attacker can probably find them within an hour for 99% of people.

You need at least some additional information that is more difficult to find out and can work as a shared secret. That is the reasoning behind the various "mothers maiden name" or "name of your first pet" so-called security questions.

If you don't have anything else, there is no secure way to check. In this case you need to make those users identify themselves in some trusted way, e.g. by going to a physical location and showing their passport, or showing their passport on a webcam or some such step, depending on the sensitivity of the data.

This is a fundamental issue that you cannot solve with technology or math, because there simply is not enough non-public information present.

So check if any of the other fields stored in that DB can be used as identifying information.


Open ports on my router's guest network?

These are open services on your network
Port 49152: As the first port in the dynamic/private range (49152-65535), this port is commonly used by applications that utilize a dynamic/random/configurable port.

uTorrent, and Azureus/Vuze p2p torrent clients often use this port.

Apple Xsan Filesystem Access uses the dynamic/private range 49152-65535 as well.


Nothing really, if your environment already employs a 20+ character password then this PIN is kind of "doubling up" on this. The RSA tokens are usually deployed as a one stop solution. You log in with your user name, you know the password and you have the token (which gives a code). The trinity of who you are, something you know, something you have.

You have the extra layer of a strong password which is stronger than then pin used for the token.

I mean, correct me if I'm wrong? but i think the only thing that this protects against in these conditions are lost keys or old keys out in the wild that are unknown for some reason. Also an end of life process that is automatic, as the keys that are more than a year old will simply not be useful to anyone down the road.

Some of the more paranoid sysadmins might think if an attacker gets a key and knows who its from it might forever be a risk, since all they have to do is find out the rest of the details, having no end in sight to that system gives the attacker unlimited time, in theory, to do recon. This rule would provide a one year constraint on finding out the rest of the details required. A sort of automatic garbage collection if you will. But that's the only thing i can think of here.


How to convince the boss of an Acceptable Use Policy

The strongest case for AUP is that you can address or discipline risky behaviour before it bites you rather than having to mop up afterwards.

On the compliance front there is the issue of employer liability for employee actions on the Internet (which I believe is an issue in the US). If the workstations handle or share a network with systems which handle credit card data you could also invoke the final requirement of PCI-DSS which states that you must "Maintain a policy which addresses information security".


AES in CTR mode. Does both parties have to know the nonce?

Normally the nonce would be 0 as in the NIST documentation:

  In  the  recommended  usage  scenario,  the  party  encrypting  maintains  an  integer  counter,
  nonce
  ,
  initially 0, and produces the string
  ctr
  as the 128-bit string which encodes the number
  nonce
  2
  64
  .  (In other words,
  nonce
  is regarded as a 64-bit binary number, and
  ctr
  is constructed by appending to this number 64 zero-bits.)  The
  number
  nonce
  is incremented following each encryption. Typically, one transmits
  C
  along with a string which encodes
  nonce.

If you choose to use an other nonce you would have to send this to the decrypter as well. More can be found in this NIST document.


Web Based penetration test that uses MD5 for password

When using Hydra, you normally use -P password_list.txt to specify the input passwords. You simply need to md5sum this list. Consider this script hasher.sh:

#!/bin/bash
filename="$1"
while read -r line
do
    echo $line | md5sum
done < "$filename"

Now you can hash your original password list:

./hasher.sh password_list.txt | cut -d" " -f1 > hashed_passwords.txt

Finally, you can use hydra against your target using this new list of MD5s:

hydra -L logins.txt -P hashed_passwords.txt <any other options> <target>


JWT or public-private keys for service to service API calls

The JWT was created to handle a wide range of situations (differentiated claims, separate identity server, many users, etc.). Your situation is fairly straight forward - you have only one client (A) that needs to communicate with one server (B).

You could handle this case with JWT if you want to, but there is no need too. It would indeed be overkill, since the JWT requires some form of authentication in the first step. And if you have to set that up, why not use it all the way through? The private-public key setup you suggest would work equally well. So unless you expect your requirements to change, I would go with the one that is simpler to implement.

Something very similar to your suggestion is actually already implemented in TLS, namely client authentication. In that setup, the client has to provide a certificate to the server for authentication. You might want to look into that.


Somebody called a number from a pop-up on their MacOS computer and installed a program called GoToAssist. What is the best course of action now?

File created/modified dates are not enforced to be accurate in any way, and can not reliably be used to detect malicious changes.

They probably did use real GoToAssist for its ambiance of credibility... this is not the software you are worried about, and not what you care about removing.

This system has been fully compromised, no utility is going to help you to be certain that no malicious parts remain.

Reinstalling the operating system and wiping the drive is the only way to even vaguely trust this computer again. This is not paranoia at all, just good practice. Make sure that no executable files are restored. One of the possible scams here is ransomware... Turn the machine off and leave it off. Do not boot the compromised system install again.

Backup the files that really matter to something that is offline and not updated with changes, like an external hard drive that is left disconnected. Change all passwords that might have been available on that machine.

Paranoia would be wondering if the machine was flashed with bad firmware or some other hardware level permanent security compromise.... Apple is probably reasonably good about security here, but there are "jailbroken" iPhones.


What should I ask a prospective security consultant?

Invent a scenario similar to the one you want them to work on, and get them to walk you through how they would tackle it. You'd want to assess their ability to understand the needs of your business as well as their technical understanding. The key factor would be whether they ask the right questions and give you the right answers.

For example, you might want someone to assess your e-commerce infrastructure, so your scenario might start with the question:

"We want to put a new website up - how should we secure it?"

A good candidate would immediately start asking about the data involved, and the level of risk you're willing to tolerate. A bad candidate would get immediately proscriptive.

If they answer that to your satisfaction, or draw the information out of you, you can expand it to:

The website will contain a shopping cart. How should we secure that?

... etc. Ideally, in this scenario, you'd have a candidate who looks at wider issues than just IT - policies, procedures, staff training, backups and backup security all play a part as well as firewalls and IPS.


How can I check what scripts are in Nmap's default category (`--script=default`)?

The scripts included in the default category (and every other category) can be found here in the NSE documentation.

Edit: additionally, you can look into each script in your scripts directory to find a line like this:

categories = {"default", "safe"}

This will tell you every category that the script is a member of, and allows you to change the membership of any script, as well as create custom categories if you wish.


One of her key requirements is, that the data stored will be encrypted
  in a way that only the user will be able to access it.

The only way to truly guarantee this is to have the encryption key reside on the client, under the control of the user.  This introduces (at least) two problems -

Having a thick enough client to support key management and decryption
Users will lose their keys and, correspondingly, their data

The first tends to rule out browser-based applications (although I'm sure someone, somewhere, has been smart enough to find a way to do it).  The second is an unavoidable implication of the requirement, and may well be acceptable to users (a user with sufficiently strong secrecy requirements may prefer data be lost than compromised).

The protections you've devised - using the user password to protect the key - only protect the user from you if you're honest.  If you're not honest, you could capture their password when they unlock the key, or capture the unlocked key when they're using it.  Or maybe you're honest, but there's a government agent standing behind you with a warrant and/or a gun.  Either way, if you really mean "encrypted in a way that only the user will be able to access it," then the user has to be the key custodian.

(Now - in fact - if you supply the client, then they have to trust that you didn't backdoor it to capture their key, their data, etc. etc.  But theoretically, since they have the client in hand, they can analyze it and attempt to detect such misbehavior on your part - just like anti-virus vendors and forensic incident responders analyze code to see what it's doing under the hood.  This improves their assurance over what it would be if the key is stored/used server side.  Realistically few people have the skills to do so, and even fewer have the motivation, but the fact that it is possible results in the perception that the client can be trusted more than the server in this scenario)


What should I think about users with huge numbers of successful login attempts in a short period?

On the security side, you can protect yourself with:

Rate limiting tools like fail2ban to block DDoS and other automated noise
Recaptcha to block brute force attempts
A stateful firewall, intrusion detection, or intrusion prevent appliance to block known attack methods

(This site forbids product recommendations, but there are packaged/supported paid products for each of those categories as well as open source options depending on your preferences.)

We can't tell you what to think beyond those basics because this type of question is dependent on data that you may not want to disclose on a public forum. Specifically:

A successful login means the client has valid credentials. You'll have to investigate the behavior or contact the user to determine whether the activity was legitimate. Investigation would include a careful review of the relevant logs. You would need to reset/revoke credentials if the activity is unauthorized.
Automated processes can easily perform hundreds, thousands, or millions of unique actions per second. This could be the result of: (a) an unauthorized tool, (b) an authorized tool working properly, (c) an authorized tool that is misbehaving for some reason; we have no way to know or investigate, or (d) an authorized tool that is being misused. You would need to whitelist the behavior, reconfigure the tool, revoke access, or block access depending on what is happening.
Do the authentication attempts look like attacks on JWT or not? You would need to block a bad actor. Preferably, an IPS would handle it automatically, but you could add rules to fail2ban or a firewall as needed.

If you are a security analyst, you should have the tools to investigate this; if not, then the organization has a deficit that management needs to be aware of. If you are not a security analyst and your company does not have one, there are security consultants that can help investigate.


Locate server by latency it has to other servers

Given enough measurements so that you can remove variation caused by server load and network congestion, it should be possible to determine the "network location" of a system. I doubt that these measurements are accurate enough to get the geographic location, but they might be at least a start.

Other information you could use are geographical information about IP address (Geo IP), which is unfortunately very imprecise and sometimes completely wrong too (sometimes points to a different country far away). Helpful might also to detect the routers in between two systems using traceroute, i.e. not only the number of hops but which hops are shared between various systems. But and the end it is probably lots of heuristics and lots of results will be wrong.

As an interesting related article see the case of the 500-mile email.


The basic idea of S-HTTP is to do everything which is done in the binary SSL/TLS protocol within the text based HTTP protocol. This by itself does not make it less secure.

What makes it definitely less security from today's view is the choice of allowed ciphers (see section 3.2.4.7 of RFC 2660) which includes only ciphers which are considered weak today. But S-HTTP is not only an old protocol regarding ciphers. It can be expected that some of the attacks which got developed against SSL/TLS in the mean time and which got fixed in subsequent versions will also work against S-HTTP. Given the time when it was developed I expect S-HTTP to be at about the weak security level of SSL 2.0 but at most SSL 3.0.


Adding self signed certificate to trusted store

Self-signed certificates

If you have a CA (private) key, which is the same as the one for the CSR you sign, then you create a self-signed certificate. If instead you create separate keys for the entity whose identity you wish to confirm and the CA used to confirm the identity, it's formally not a self-signed certificate anymore.

Self-signed certificates are mostly used for testing purposes and thus temporary. This can be enforced by limiting their validity period, but often isn't done in favor of convenience.

How the real-world CAs do it

The CAs will have a hierarchy of keys/certs (comprising the certificate chain you probably have heard of). If you - or your OS vendor - choose to trust a root CA cert it implies trust to Sub-CAs whose certs were signed with the root CA key.

What this means is that the root CA key requires the highest security, because it can be used to create any number of Sub-CAs which will be ultimately trusted if someone chose to trust the root CA cert.

  Be sure to delete any temporary root authority certificates from the
  Trusted Root Certification Authorities and Personal folders by
  right-clicking the certificate, then clicking Delete.

Makes perfect sense now, if you consider that a root CA cert (with key) proper will have the biggest potential of being abused and create the biggest bang for the buck for an attacker. if compromised. You'll want to keep those stashed away securely unless you are using them right now to sign a Sub-CA CSR. Hence, remove them and keep a copy for later CSR signing purposes (if you need).

However, since the quote is clearly about "temporary root authority certificates", I think the clue is hidden in temporary and that's something you as the system administrator define for your own CAs and Sub-CAs (i.e. whether you intend to use them in the future or not).

Basically you can consider deleting a temporary CA cert/key as making it unavailable to an attacker, similar to the security measures of actual root CA keys. It assumes that this temporary CA won't be used to sign any more (development-use) certificates.

So that little word temporary implies a little more in the quote than it seems at first glance.

How this looks in practice

Let's say you have a root CA key that never expires (although in most cases it will simply be a relatively long period, like 20 years) and a corresponding root CA cert. You'll want to keep the key secure from any compromise, especially if the certificate is trusted by many many people. That is the case with the root CA certs of, say, Verisign or Comodo.

That root CA key will then be used solely to sign the cert of a Sub-CA (which has its own distinct key), thereby creating the first two links in a certificate chain which your browser or Microsoft's signtool as well as many other utilities let you inspect. The root CA key would never be used directly to process your CSR and thus confirm your identity as an end-user/website/company.

Every respective Sub-CA will usually only be used for a particular purpose (there are extra fields for certain purposes, such as code-signing) and its validity period will be a subset of the root CA cert's.

But, and that's one difference between the root CA's key and the Sub-CA's key: the root CAs key can be stashed away securely (talking physical security here) most of the time, unless absolutely needed to sign the CSR for a new Sub-CA, while the Sub-CA key will likely be used on some kind of highly secured server to sign customer CSRs (when considering a real-life certification authority like Verisign). This means that the Sub-CA is more at risk than the root CA and why you want to apply different levels of security in the first place.

The advantage being that, should the Sub-CA ever get compromised, its certificate can be put onto a ARL/CRL (authority/certificate revocation list), whereas putting the root CA certificate on a ARL/CRL is only really warranted for technical reasons (e.g. using the now compromised MD5 hash, a key length not deemed secure anymore ...). The costs attached to either of these are the defining factor at several levels:

costs for storing the keys securely, in particular the root CA key has to be secured the most
costs when changing root CA certs versus changing Sub-CA certs
costs when revoking (Sub-)CA certs


Attacker models of long-term logins: how should sensitive server endpoints require re-authentication?

The "level of assurance" of the authentication (how much you trust that the user is who she says she is, is usually stored in the standard-defined claim "acr". It's usually between 1 and 3, and is set during login based on the form of authentication. 2 factors give a higher acr than just a password, for instance.  NIST SP 800-63 gives some more details.

What you can do, is to require a certain acr value for important endpoints, and require reauthentication if the level is not high enough.

This solves your problem, if you have a mechanism to reduce the acr value over time  or when issuing long lived sessions. Then Alice is only able to use the "ownership" functionality for a short period after logging in.


What are the tradeoffs in allowing logouts of other logged-in sessions?

The feature is really useful from a security perspective as it allows users to easily notice if someone else is accessing the account. This is a really useful feature in the sort of attacks where the attacker would want to silently observe the account to obtain information without actually doing anything active which would draw attention to himself.

The biggest downside I can think of would be an attacker being able to perform a denial-of-service attack against currently logged in accounts. Of course this isn't much of a downside as the attacker could do far worst if he is able to access your account.


Can a hacker use someone else's IP address when running a scam?

If the suspicious emails are from a consistently different IP than the trusted emails, then it seems unlikely that his computer is compromised. Instead, it sounds like someone has found a way to spoof his email address, using their own computer to send it.

Without knowing more information, I can't really speculate as to why someone is doing this. However, there are steps that can be taken to verify that emails are actually coming from your friend, rather than a scammer.

One approach you could use is to sign the message using PGP. In order for that to work, you would both have to set up a mail client (or use a plugin) that knows how to deal with PGP signatures, and then your friend would have to generate keys and send you the public key somehow. At that point, you'd be able to verify that future emails are coming from the "correct" source - or at least, from the source that originally gave you a public key. To really be safe, you'd also want to confirm the key's fingerprint using a trusted channel (like voice chat), in order to verify that the public key is actually from your friend, rather than from some malicious third party.

There are other approaches that could be used on your end to check whether a message is legitimate, although those are likely to involve a bit more specific knowledge about the email servers involved. In comparison, PGP will work in any context, although it requires that both parties have at least a bit of extra cybersecurity knowledge.


Is the MySQL database on the same machine? If so can you just pull the database files and reconstruct the DB on your machine?

As others have stated you can pull /etc/passwd which contains a lot of information about the user layout. If you can access /etc/shadow you can attempt to offline crack passwords.

If the web application has a login portal attempt the mysql credentials as well as "admin", "root" etc. with the password.

Does the source code or config files contain any other access credentials / API keys? Is the sites SSL certificate readable - if so you can Man In the Middle connections?

You can also pull details from /proc/version, /etc/issue etc. and the webserver versions to look for other known vulnerabilities.

Finally is the source supposed to be public? If not source code is often viewed as valuable. And you can inspect that for further vulnerabilities.


How to securely provide SSL certs to a Docker app

One challenge with the environment variable approach is that they are shared with any linked containers (more info here), which may restrict the use of that approach in some setups.

Private images as you say are a problem as you're sharing the key to a number of parties and this could also affect your ability to use other related services which would need access to the github or docker repos (e.g. Jenkins)

This leaves the mounted volume solution, which seems like the best approach from a security standpoint.  It restricts the necessary distribution to the docker host, which in most cases is less of an exposure than placing it with 3rd parties or potentially exposing it to other linked containers.


Are there any security related rules in PCI-DSS that govern when I can capture a payment?

The matters of payment capture and shipping aren't covered or related to PCI DSS.


PHP Image Upload - Security of storing outside root and accessing via readfile()

Reading the file from outside the webroot with readfile(), it won't be able to run a malicious script on the server.

Providing the proper content-type means that it won't be mishandled as something else in most cases.

However, there are still some cases such as Gifar where a polyglot content is provided in a way that can affect the user (these are actually problems in Java or Flash, but breaking the same-origin), so you should check that the content really is what it to be, and it is not one of certain undesirable formats (for instance, zip-based formats are quite problematic).


Principal DOM Based XSS detect using python

I can't look into your problem, as you gave a fake URL for testing XSS.  Here's a real URL demonstrating an XSS vulnerabilities:

http://www.insecurelabs.org/Task/

Using the first task this is a URL that has an XSS vulnerability:

http://www.insecurelabs.org/Task/Rule1?query=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

Using requests python library, we can request this page:

>>> import requests
>>> xss_url = http://www.insecurelabs.org/Task/Rule1?query=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E
>>> r_xss = requests.get(xss_url)
>>> print r_xss.text

<!DOCTYPE html>

    <meta charset="utf-8" />
    <title></title>
    <link href="/Content/Task.css" rel="stylesheet" type="text/css" />

            Back to task list

Task 1 - between tags

    <form method="get" action="">
        Search: <input type="text" name="query" value="&lt;script&gt;alert(&#39;XSS&#39;)&lt;/script&gt;"/><input type="submit" value="Search" />
    </form>

        Searched for

        Found nothing.

    ...

As you can see right above where I truncated the rest of the HTML content, there is the text Searched for , which is the XSS vulnerability as it is a fully formed


TLS and self-signed certs. Is hostname verification necessary if client-supplied CA is the same as server leaf cert?

A check of the subject is done if the CA has issued many certificates for different servers and thus just checking the CA (i.e. trust chain) is not sufficient to specify the expected leaf certificate.
But if the expected certificate can be specified with sufficient precision by other means the validation of the subject is not needed. This is for example the case when checking the certificate or its public key against known good values (as done in certificate pinning or public key pinning). This would also be the case if the CA is known to have definitely only issued certificates for this specific site. This is also essentially what browsers do when the user explicitly adds an certificate exception for a site: they remember this certificate as trusted for the specific site (but not for others), no matter if the subject matters or not.
Trusting a specific self-signed certificate by importing it in the trust store is basically pinning to this specific certificate. No further checks of the subject would be needed in this case. Note though that the browser does not know that this self-signed certificate can not be used to sign other certificates if it is imported as a trusted CA - it must assume that it is a generic CA which can issue other certificates and thus subject need to be checked.


HMAC is generally more applicable to situations where two entities want to communicate securely over the internet. It provides two key things, confidentiality and integrity. confidentiality by proving the remote client has possession of the "secret" ingredient, integrity, through validation of message digest.

In your use case, local storage encryption, encrypting the Symmetric key with RSA Public key should work just fine, so long as you are protecting the private key with strong protection mechanisms.

One more thing, in step2, why are you hashing the message digest with RSA private key?, It's better to use the public key instead.


The 'Public' profile allows anyone who can log into the system access to the contents. You may still be able to limit it with NTFS permissions, but if you are trying to do proper access controls via NTFS on the files you should really use a folder outside of the user profiles in general. Then you can block inheritance and set your own permissions.


Mod_security rules-updater.pl fails to pull new release

It's looking for 2.2.3, which isn't there, so no surprise it fails. Sounds like you should report a bug  to them.


Why does moving my mouse really quickly make recaptcha pass quicker?

I am assuming that you are talking about the No Captcha ReCaptcha here. This tick based ReCaptcha works based on javascript and a CSS styling element unlike the form input based conventional CAPTCHA. Google is relying on the fact that most bots doesn't have javascript support and will not be able to fire the ajax request which is usually fired when the user clicks on the check box. It may also be relying on the javascript to capture mouse actions. More mouse actions create more entropy which a bot ideally cannot mimic. This could be the reason why your random mouse movements made an easy pass through the reCAPTCHA.

This is an educated guess.


If a phone is encrypted at a platform storage level do I need to encrypt my data stored on it?

I will first address the various attack vectors possible if the device is on or off and whether full disk encryption (FDE) is on or off. After that, I want to comment about the need for app-level encryption and the capabilities that it offers in your particular scenario.

Here, we assume the attacker has obtained control of the device. Furthermore, we assume that he or she is a well-educated hacker who has the time and resources to extract data out of the device. In real life, you may meet these people (but you may also meet those who are just interested in wiping the data and reselling the device).

Oftentimes, it comes down to the user’s habits that ultimately determine the security of the device. Let me mention a few of them (non-exhaustive).

(a) How does the user unlock his device? Pin code, swype pattern, picture, Touch ID, or none at all? Pin code is the strongest if there are sufficient digits. Swype patterns can be deduced by shining some light onto the phone and tracing out the oil stains. Picture and Touch ID are not fool proof either. See proof of concept videos on YouTube showing Touch ID being hacked.

(b) In addition, is the user conscious of his surroundings when unlocking his device? People may simply peek and memorize the patterns.

(c) How many seconds of standby before the phone automatically locks itself?

(d) Is the user running third party lock screen apps or any other types of apps which may introduce specific security vulnerabilities?

If the phone is unlocked, then the next thing stopping the attacker is any security authentication features built into your specific app (which I cannot comment on since I do not know your implementation). Just imagine you are an attacker now. How easy is it for you to launch up your app and see the data? What if the user recently switched apps? Does switching back to your app afterwards allow you the access the app or not (i.e. is the “login” persistent across app lifecycle states?)

Now, assuming the pin code is secure and the phone is locked at the time of theft, then a manual brute force attack (i.e. the attacker using his fingers to guess the password) is unlikely to work out. However, the attacker may try to do an automatic brute force attack using software tools. Just like ‘password recovery’ or ‘data recovery’ tools out there, you have to connect the phone to the computer and run the recovery tool. In this case, the phone is on. The success of running such forensic tools depends on the following:

(a) Is the device rooted or jail-broken into? Many recovery tools rely on this in order to get superuser rights and security privileges to crack the password or extract the data.

(b) Is developer mode on? Legitimate tools like Android Debug Bridge (adb) may be able to get data out of the phone if developer privileges are enabled. However, in later versions of Android, this should not succeed if the phone is plugged into a completely new PC since authorization must be given on the phone itself (an RSA fingerprint is registered). I am not sure about Apple or iOS.

(c) Is there a malicious or vulnerable third party app already installed in advance that the hacker can communicate with? For example, there may be some bad app that can remotely unlock the victim’s phone once the attacker gets hold of it.

P.S. If you can find a brand new device that can be hacked without the aforementioned conditions, do let Google or Apple know immediately, as this means their default OS implementation is insecure.

Notice that I did not mention FDE as it does not really help prevent the aforementioned attack vectors. If an FDE-enabled device is on at the time of theft, the OS is automatically triggered to do on-the-fly encryption and decryption of the disk sectors that are required by any app anyway. That’s how users can use their apps normally. Similarly, if the attacker’s tools are allowed to run on the phone, then FDE is not going to help, since the OS will cooperate and decrypt the information on-the-fly. In other literature, you may encounter the saying the FDE is mainly there to protect against offline attacks, and not online attacks.

Okay, let’s assume our phone has survived the attacker up to this point, due to our prudent user habits and the fact that we didn’t root and mess up the default security in our device. We have also enabled FDE, so the attacker cannot simply plug the phone in and read out all the data. Even if he transplants the hard disk from one phone to another, the other phone should not be able to read the data since the data is encrypted at rest.

The attacker is left with 2 main options to defeat FDE.

(a) Cold boot attack

(b) Direct memory access (DMA) attack

Now, cold boot attack takes advantage of the encryption key being in volatile memory (RAM). By cooling down the device, the electrical charge stays on for just a bit longer, long enough to plug into some other device/OS and read out the contents of RAM, thereby obtaining the key. In my opinion, this doesn’t seem as easy to do on a phone compared to a desktop with upgradeable memory, given that memory is built together with the motherboard. Also, this is quite impractical as the attacker has to train his skills on a specific hardware phone model.

Cold boot attacks might be mitigated if the phone is switched off at the time of the theft since the key should not be released to memory, however it does not apply to all systems! It ultimately boils down to how Android and Google have implemented their encryption schemes in their operating systems. At least for Android, I know the user has 30 tries to key in the right password upon turning on the phone before Android is booted. This seems to suggest that Android does not release the decryption key until the correct password is given. In a totally separate computing platform, Windows Bitlocker with TPM will release the decryption keys as long as it verifies that the boot partition hasn’t been tampered with; it has nothing to do with the user account credentials that one uses to log into Windows. In other words, shutting down the computer will not make a difference since the attacker can start it up again and the TPM will still release the keys as long as the integrity check passes. Of course, Bitlocker does come with two-factor authentication to counter this problem if you really want it.

In short, I just want to caution that while shutting down the device may seem a good practice, it is not a practical one in the mobile world, and it may or may not mitigate the cold boot attack depending on the details of the implementation.

The next attack used to defeat FDE is the DMA attack. Since Android phones do not come with DMA ports, I think this should not be possible. As for Apple mobile devices, thunderbolt may be exploitable, but I have not researched into this area to give a conclusive answer to this.

Now, let us move on to the real problem where FDE is concerned.

Security experts are happy that Android has finally caught up to Apple in providing default encryption with Lollipop, however, that’s only for new Lollipop devices. FDE is not enabled by default on pre-Lollipop Android devices (even if you upgraded from Kitkat to Lollipop, you still have to turn it on manually). That is a huge number of devices that would persist for the next few years!

Therefore, it may be wise to attempt to have an app-level encryption of our app data for a specific app, as you have alluded to. However, the devil lies in the implementation details. Many “secure” apps on the app store cannot really be trusted unless the source code is available for scrutiny.

One vulnerable implementation I can think of is to ship the app together with the encryption/decryption key. This sounds really convenient for the user – just fire up the app and everything works. No need to keep keying in passwords, since the key is stored somewhere. Okay, so the app data is encrypted and decrypted using the key is stored in plaintext. However, assuming that the device does not have FDE, the attacker can still obtain the key and use it the decrypt the app data (although it may slow him down if we do some obfuscation). This is definitely insecure.

One secure implementation I can refer you to is that of Truecrypt. It is an offline encryption software for computers that is open source. Although it has been a discontinued project as of 2014, experts believe it is still secure and some groups are trying to continue to maintain Truecrypt. It does not store the encryption key on the hard disk. Take a look at the details of its encryption scheme here http://andryou.com/truecrypt/docs/encryption-scheme.php . You can also check out the FAQ to find out more.

I believe you can adapt the scheme to your app. At the cost of convenience, make the user key in a password every time they start your app. The password will be input into a key generating function to generate a long AES key, and the key will persist in RAM until the app closes (like others have mentioned). It is never stored on the hard disk, In this case, it is still vulnerable to Cold Boot and DMA but it does not seem to be likely on mobiles at this point in time.

Another example I can point you to is Lastpass for mobile. It is a secure password manager that has extended its functionality to the mobile space. Maybe you can delve into how they implement their crypto schemes securely and how their app works (if I recall correctly, it also works offline).

Once again I like to stress that encryption does not defeat all attack vectors. If there is a malware running, then that malware could still get hold of the data while the user is using your app. Best weapon to fight this is user education.

Some final comments for now:

If a device is compromised, the user should do a remote wipe of the device. If FDE is enabled, the data is most likely unrecoverable since the key is lost after wiping.

In addition, the user should immediately change all of his passwords for active accounts logged into the compromised device.


How to detect if a user is logged in to a specific website?

There is no universal standard about what "being logged in" actually means, so there is no universally applicable solution.

Depending on the website, the attacker could use a javascript which attempts to load an image or other media file from the external website which can only be requested by a user which is logged in. When the user is logged in, the load event will be triggered, otherwise the error event will be triggered.


Is Apache serving over HTTP vulnerable to Heartbleed?

Teun Vink is right, it's not vulnerable if you are certain that https is turned off, for example by turning mod_ssl off.

Even if you don't actively use https, it may still be enabled. Many servers have https enabled by default with some automatically generated certificate. This will not be valid and throw an error or warning in browsers, but it will still be exploitable.

If you can modify the apache configuration, disable mod_ssl with a2dismod ssl. On Windows I'm not sure this works; for example in a xampp installation you should edit the httpd.conf file in the xampp/apache/conf folder. Put a pound sign (#) in front of the line that says
LoadModule <something_with_ssl> so it becomes #LoadModule <something_with_ssl>

If disabling mod_ssl causes problems in other parts of the configuration, you can also simply make sure that the only Listen option is for port 80. You should search in all configuration files for those Listen options, for example with grep or on Windows you could use Notepad++' search in files feature.

In any case, it's advisable to update OpenSSL if possible. Other stuff may be using it, or someone may turn https on in the future without realizing that it's vulnerable.

TL;DR: Update OpenSSL if at all possible, even if you are not vulnerable. If not possible, make absolutely certain you're not using https.


Feasibility of creating an in-memory web app (that runs from a CD-rom on a web server) for sharing self-destructing messages

Technically feasible?  Certainly.  It doesn't sound different from any other live CD, just with a server-oriented environment rather than the more traditional desktop-oriented one.

What advantages do you picture this having, though?


Security precautions for shared iPads in a customer facing corporate environment

We've recently been testing Good for Enterprise which has turned out to be great. Users can install it on any device IOS or Android (assuming it is compliant to your standards(ie not jailbroken for example)) then set up quickly and easily. All your personal data (email, contacts, documents etc) are synced and stored within the encrypted application. If you unenroll one user and re-enroll another then there won't be any remnant data on the device inside the app so it could easily be shared between users. Set up takes a minute or two and is quite painless. You can also push out applications to the users via the 'Good' application.

Other things that might be  of interest to you, Defense Signals Directorate IOS Hardening Guide
and a list of mobile management software.


Password protecting folder in windows using a .bat/ .exe file: is it such a bad practice?

This batch script doesn't protect anything at all. It just renames the folder in question and sets the system and hidden attributes, which makes the folder a little bit harder to find and might keep your ten-year-old child from seeing it, but it won't stop anyone else.

At most, we might call this "security by obscurity", but I'm hesitant to even call it that, because in reality, setting the hidden and system attributes don't obscure that much.

There is no encryption going on at all – the folder doesn't get password-protected, the password is only used in the batch file to block someone from using the batch file to automatically remove the hidden and system attributes and rename the folder back to something sane.

  Would this be easy to crack after we export it into an .exe file?

Yes. Simply extract all strings from the .exe file and you'll find the "password".

  What if I encrypt the .exe file for extra security?

Again, the script does not provide any security at all. If you encrypt the batch/.exe file, you make it harder to use, but you don't actually make the folder in question more secure.

  What are those keys like 21EC2020-3AEA-1069-A2DD-08002B30309D?

These don't mean anything by themselves (edit: see Bob and Danny's comments about junction points for an explanation of their meaning). They might be part of a larger system the batch file is part of, but they don't add anything to the security of the actual folder – it's just part of the folder's new name while it is "hidden".

What to do instead

You've already said it: Use BitLocker or VeraCrypt. Veracrypt can work with container files which will contain a whole tree of folders and it offers real security, as does BitLocker.

If you don't want to use any extra software, do what Mike suggests and zip the folder, protecting it with a password. This offers you nowhere near the security of BitLocker, VeraCrypt, and compatriots, though.


Putting aside that you are using Nessus, let me answer in terms of the use of any web application scanner as a tool.

Automated scanners are great tools for a quick, repeatable test that can find the most common issues with websites. I would never develop without running automated tools.

But, one always has to understand that these tools come with serious limitations and weaknesses. No tool is perfect.

So, it depends on the outcome you want. If you want a comprehensive understanding of your code, then you need a full process to cover your code. Things like:

code reviews
threat modelling
automated scanners
manual tests
3rd party manual tests

For every thing you decide not to include in your process, you also choose to lose that level of completeness of understanding.

If you depend solely on automated tools, you give up a LOT of understanding. Even if you use tools, it is still a good idea to understand all the common attacks on websites, yourself, and understand how to check for them manually. If for no other reason, than to check on false positives.


Is online banking more secure on iOS than a desktop computer?

If you are using an IOS mobile device, your device is subject to many attacks such as

Juice jacking
A web browser that doesn't show HTTPS status clearly (iPhone)
A web browser that doesn't show the URL... enabling phishing (iPhone)
Web browsers that don't support additional SSL/TLS validation software such as Convergence

If you must use a mobile device, I'd suggest using a dedicated application, as this post suggests.  In addition, the application itself may also validate the HTTPS certificate key (preventing MITM attacks) or even better it may use mutual auth TLS

(The following is similar to @Rory's answer:)

The ideal solution, is to reformat your PC, and install a virtual OS for games, testing, etc.  Then use the standard PC for all your banking needs.  Since the VM can't access your PC (hopefully you configured it so) then you're safe from any phishing or other attack.*

*  Exception


Arp poisoning doesn’t work with HTTPS navigation

With an ARP spoof, you intercept only the Ethernet layer. To have a ManInTheMiddle position, you need to spoof both client and server and enabling forwarding.
Without that, when your victim computer tries to browse tinder.com, the IP layer is built with the IP of tinder.com and sent to your evil computer (if you spoof the gateway address or the tinder.com address).
If your evil computer does not have a web service listening on port 80, tinder.com will appear unreachable for your victim computer.
Maybe you also intercepted the DNS request and the victim computer never received the Ip to use to contact tinder.com
If you configured your ettercap attack to forward the captured packet to the real destination, you should be able to see the cleartext traffic. I remember that ettercap tries to spoof the SSL layer by default. If yes, your problem could come from the fact that ettercap displays an untrusted certificate to the victim and the tinder.com is configured with HSTS to avoid this.
If you disable the ssl interception (with -S) the victim should be able to reach tinder.com but you will not see the content of the HTTPS layer (you will only see the Ethernet, IP, and TCP layers)


If you sniff on the exit node and the connection is not https/hidden service, then you will have the traffic in clear but you will not be able to know from who it came. Unless the traffic itself is revealing the identity.

In other cases, as far as we know, you can't decrypt tor. As other said, tor will be useless if it was possible.


How secure is my software for file encryption with AES-256?

First: Please don't roll your own crypto.

If you're doing this for production purposes I've to strongly recommend against using it. If it you want to improve your programming skills or this is a smiliar research project, it's fine as long as you do not expect strong (professional) security from it.

Now to the actual points which are improvable on what you gave here (in order of appearance in the post):

PKCS#5 PBKDF2 with HMAC-SHA-256. Please. PBKDF2 is an old standard for password based key derivation and should be replaced by at least bcrypt or even better Argon2. Also see our canonical answer on password hashing.
100,000 iterations. Please don't hard-code the iteration count but rather dynmically find it at run-time depending on what the CPU can do. This is especially true if you don't know your exact target platform and if your software will be around for some time. TrueCrypt also fell about this issue.
8-byte salt. While an 8-byte (=64-bit) salt may be fine, a 16 byte (= 128-bit) salt is a better choice, to prevent pre-computation attacks on the limited range of salts.
SHA-1-PRNG. You didn't give any details about this one. This looks OK, but you should upgrade if possible (to SHA-256 or SHA-3), to avoid SHA-1 which is still OK for running a PRNG but may shine a bad light on your tool for using such an old and "broken" algorithm.
16 byte IV for AES. Note while this is the appropriate choice for CBC, CFB, CTR, OFB, ... (i.e. all unauthenticated encryption modes) it usually isn't the appropriate choice for authenticated encryption modes which require a 12-byte nonce for optimal security. If you can guarantee unique keys (which it looks like you can), you can let the nonce default to all-zero.
AES/CBC/PKCS5Padding. This would be an OK choice (not a good one!) if you'd have some means to authenticate the message (i.e. confirm it hasn't been tampered with). You don't, so the better choice would be to use an authenticated encryption scheme like AES-GCM, AES-CCM, AES-EAX, ...
The associated data (salt + IV). First, you can let the IV default to some value (all zero?) if you files stay small (less than 68GB) and use AES-GCM. Second, you should authenticate this data as "associated data" and add an authentication tag (in clear) at the end of the file (decent libraries will do that automatically). If you were to use this is as it stands, an attacker (who knows the first block) could change the IV to make the legitimate user decrypt a plaintext of the attacker's choice. Additionally you'd want to add the key derivation parameters (like iteration counts, time and space parameters and other configuration) to your associated data to ensure long-term adaptibility of the format.


Is it possible to reliably derive a key from a biometric fingerprint?

Reliably deriving cryptographic keys from biometric data is hard because of thresholds: biometric data is a continuum, but cryptographic keys are binary: a bit is a zero or a one, not something in between. Whenever you design a scheme to transform biometric data into keys, there will be people whose biometric data falls "on the edge" and who will get a wrong key half of the time.

However, this does not stop people from trying. This is an active research area, which does not suffer from an impossibility result (it is not proven that it cannot be done). See for instance this article, and that one, and also that one, and, in particular, this survey.

Executive summary: it does not work... yet.


Password hashing algorithms suitable for IoT devices?

No password hashing algorithm is suitable for resource-constrained devices. That's because password hashing must be inherently slow. It needs to be slow on the attacker's computer, and yet not unacceptably slow on yours. But if your computer is slow, such as a microcontroller, what takes a few minutes on your computer only takes a fraction of a second on the attacker's computer.

Do not store passwords on an IoT device. A typical IoT device doesn't have a keyboard input anyway, so why would it store a password? If you need to authenticate, use an authentication token which is not meant to be memorized by humans, and thus verifying it can be a simple hash or signature verification, and not a password hash. If you need the user to authenticate with a password, this should happen on a control server which is a full-blown PC (in the cloud or on premises), and the PC generates the authentication token for the IoT device.

When it comes to choosing cryptographic algorithms for constrained devices, don't overthink it. The benefits of fine-tuning nonstandard algorithms tend to be marginal in practice. Use standard algorithms such as:

SHA-256 or SHA-3 for hashing. (That's hashing data for integrity — not hashing passwords, which as I said before you cannot do.) SHA-3 has the best performance when implemented in hardware but the hardware isn't out there yet.
RSA or ECDSA (with P256r1) or EdDSA (with Curve2519) for signature verification. RSA verification is faster than ECDSA/EdDSA verification, but signature generation is a lot slower and RSA requires more RAM and has larger signatures.
AES-CCM or AES-GCM or ChaCha20-Poly1305 for encryption. ChaCha_Poly is faster in software, but Cortex-M systems with hardware acceleration for AES are getting more common.


Safe to sell used Android-phone without doing factory reset

Greed.

You have to see which you value more, peace of mind vs the scrap money you get selling a phone that is clearly faulty & close to unusable

Retrieving data from a locked/faulty phone is definitely a thing, it is a craft people possess, it is a possibility which you have to face, and you can't simply rely on us to assure you that the possibility is close to zero.

I honestly would value privacy & data-security over extra pocket-change any day of the week. I hope you can see where I am coming from, it's just not worth it.


Using an example to comprehend why “safely” erasing a drive yields better results than filling it up with meaningless data

There was a worry that hard-discs (of an appropriate vintage now) would be vulnerable to having overwritten bit read. Rebutted here: https://www.nber.org/sys-admin/overwritten-data-guttman.html
Therefore schemes were devised to do multiple passes overwriting the data enough times and randomly so that no future development could extract data.
For a USB stick the main risk is probably 'bad blocks' - where the original data is preserved read-only, because the re-write failed. In this case it doesn't matter how many times or how cleverly you over-write it; someone who can dismantle the drive and read the flash directly can extract (some of) your original data. Drives handle bad-blocks by over-provisioning - the stick has more space than is exposed to the operating system, and remaps bad-blocks to the reserved space when they fail. Flash tends to fail read-only (i.e. fail on write), so the old data is present, if an attacker reads the flash directly.


Is there a security benefit to testing HTTP header presence with Javascript?

It depends on the header, and on what the library is designed to handle. Let me go through each header and explain if it would make sense or not:

Does specifying Content-Type make sense?

Yes and no. It's certainly nice for the server to tell us that the response is in JSON, but it is by no means a requirement. It would make sense to throw an exception if the Content-Type was something unexpected, such as application/xml. However, to throw an exception if the content type was not specified seems overly strict. It doesn't give any security benefit either, since the application has to ensure that the consumed JSON was parsed correctly.

Specifying the charset is a "nice to have", as well, but I would wager defaulting to UTF-8 if no charset was specified should be the norm. An exception because the charset was not explicitly defined is overkill.

Does specifying X-Content-Type-Options make sense?

The X-Content-Type-Options header is designed to tell browsers "Don't try to figure out what this is on your own. Just trust my Content-Type header. Your library is not a browser, it probably doesn't try to figure out what kind of content it receives based on whichever parser doesn't throw an error. The fact that the library throws an exception if this header is not present likely indicates that the behavior of "Just parse whatever you get as JSON" is hard-coded, so demanding a header that tells the library to behave how it already behaves is pointless.

Does specifying Content-Disposition make sense?

No. The idea of Content-Disposition: attachment is to kindly ask the browser to download and save a file, rather than to display it. This can be nice if you want the user to download a file (e.g. a video), rather than to display it.

In the context of a JSON response of an API, this makes no sense whatsoever. Forcing the API to instruct the browser to download a response instead of displaying it inline just makes debugging harder. It's pointless, it makes your life harder, and it has no security benefit whatsoever.

Does specifying X-Frame-Options make sense?

No. The idea of X-Frame-Options is to prevent clickjacking. An API response is not an interactive website, and it makes no sense for an API consumer to demand this header to be set.

So, what should I do?

Remove these checks, plain and simple. They don't add to security and reduce compatibility.

The only checks that might make sense is the Content-Type header, but even then I would only throw an exception if the content type is something other than application/json, meaning that the server bothered to check and is sending something that the library knows it can't parse.


Vuln research: reverse engineering, debugging or fuzzing?

The basic path for exploiting an overflow-related vulnerability is to find a crash (often by fuzzing), evaluate the crash and whether it presents an attack path, and then build something to exploit it.

Sometimes where one looks can involve knowledge of the architecture, such as when Charlie Miller noted that iOS 4.3 has a section of memory which will run unsigned code. In the case of all his Apple attacks, I believe the source was closed. SQL injection weaknesses are similar -- you're starting with a crib knowing where a good place to look is.

While it is simplest to identify and correct a bug via source after finding a crash, the work to setup the environment can be without value if one's goal is simply to write a working exploit. Often, the relevant space of a program will involve looking at less than 1 KB of machine code.

From my perspective, open source allows one to view bugs being added as they happen and say, "Hey, that bit of source looks insane." Beyond that, the work for exploiting closed-source and open-source work is often the same. As for reverse engineering, that's rare unless you're trying to alter or recreate an application rather than launch an exploit from it.

I wouldn't underestimate the ability of hacker groups to dedicate a lot of computing resources to a task. Warez groups have been known throughout the history of the Internet to muster substantial storage and bandwidth resources. It might be naive to think hacker groups don't muster the same scale of CPU power.

Finally, most people who do this for a long enough time keep a discovered exploit or two up their sleeves rather than releasing it.


As long as you are working with only online needs for the password for integrating with a system while the user is logged in, then you should store the passwords encrypted with both a database key as well as a derived key based on the user's password for your service.  When the user submits the password for their login, you can use that to produce a password derived key and use that PDK to decrypt the value from the DB.

You encrypt with the DB key itself to ensure strong encryption against an offline attack where only the DB data is lost.  You utilize the (much weaker) PDK to prevent trivial compromise in the event that the DB and the DB key are both lost.

The key in designing a system like this is to try to put the pieces needed to get to the password in as many distinct places as possible.  If you have a piece on the DB server (db key), a piece on the web server (db connection credentials), a piece in the DB data and a piece that is only in the user's possession, then an attacker must compromise far more areas to make the system fail.


How do I stop my IP from being resolved through my Skype?

Due to an increase in DDOS attacks in the gamer community Skype no longer allows an IP to be shared by default as of 01/21/2016. They are likely no longer setting up the handshake and making you a peer to peer connection and you are now transmitting information through a central server or a proxy server to make this happen.

  Skype is fully committed to delivering as safe and secure of an
  experience as possible to our customers. We have recently introduced
  the ability to hide a Skype user’s IP address and we’ve set this as a
  default status in the latest versions of Skype.

  Starting with this update to Skype and moving forward, your IP address
  will be kept hidden from Skype users. This measure will help prevent
  individuals from obtaining a Skype ID and resolving to an IP address.

  You can find this update in the latest versions of Skype on desktop
  and mobile* devices, which you can download here. We also recommend
  you update Skype across your devices to ensure you benefit from the
  best experience possible.

  *Android, and coming soon as default on iOS.


Security vulnerabilities when sharing files between virtual machine and host

As MiatoHatola pointed out, moving possibly infected files from the VM to the host system exposes the host to all the dangers the VM is exposed to. You can migitate that danger, for example by automatically scanning files in the shared folder, or by removing most software from the host that would be used to open these files. For example, you could remove the web browser from the host system, which would force your mother to use the VM to browse the web (humans are lazy; she will forget to open up the VM if she can just run the browser on the host) and remove all browser exploit attack paths from the host system.

Thinking about this a bit more, you might arrive at the conclusion that it makes more sense to do certain tasks entirely in the web browser VM, and other tasks entirely in the host. This will reduce the number of files your mother must shuffle from VM to host. Then you might think about moving all tasks to special VMs: For example, there might be a VM for everything that's untrusted, e.g. web surfing, reading mail and looking at documents downloaded in the untrusted VM, and a VM for everything else that's network related, but trusted, such as E-Banking, and yet another VM for doing stuff that doesn't need network access (personal finances, writing letters, doing your tax returns etc). For this VM, you can remove the virtual network interface so it can't possibly connect to the network. The host would just be there to start the VMs.

The advantage of this is that you reduce the attack surface significantly, because you isolate tasks from each other and reduce the amount of data that must be exchanged between the VMs. Also, if malware such as ransomware actually makes it to one of the VMs, you will most likely notice it before it can spread to every other VM. So the damage stays localized.

The disadvantage is that it makes working with the computer more difficult. Your mother will need to remember which VM is for which task, and she'll need to put up the discipline to use the correct VM for the task at hand. You can enforce some of that, for example by making the firewall only connect to trusted sites from your "trusted network VM", and by controlling which software is available in a VM, but it's still a bit of a hassle, especially when she wants to do something for which there isn't a clearly defined task boundary.

Qubes OS is an Operating System built on this idea, and tries to streamline the involved workflows, but it's probably not something your mother is going to be happy with.

If your main point of worry is another ransomware attack, diligent backups are a much easier solution.


Is Password Less Login mainstream? What sites are using Password Less Login?

I know https://medium.com/ is using it. They send link to your email address and you should click on it to let you use the service.


Can a blog owner trace my IP address when I use incognito mode?

If I comment by visiting the blog on an Incognito window, will the blog owner have access to my IP address and location?

Yes. Incognito mode just stops your browser from keeping history.

  If yes, is there a way to guard my IP and location from being visible to the blog owner?

You can use a VPN or anonymyzing proxy.


The output format of search in msfconsole

Let's go through each entry and see what it does:
#
This is the number associated with the result. While at first glance it seems useless (pun intended), you can type use 0 to use the first result, instead of typing use auxiliary/scanner/http/ssl_version. This is a very handy shortcut.
This doesn't just work for use, but every other command that takes a module name as argument (e.g. info).
Name
This is the name of the module, specifically where in the repository the module can be found. Generally, the name describes somewhat what the module will do. In this case, auxiliary/scanner/http/ssl_version shows it's an auxiliary module (meaning it does not directly exploit anything), and that it scans a http server for which SSL and TLS versions it supports. It's pretty self-explanatory, really.
Disclosure Date
This refers to either when the vulnerability was disclosed, or when the module was added. For exploits, it makes sense to check when the vulnerability was disclosed, whereas for other modules (e.g. the above-mentioned scanner), it makes sense to add when the module itself was added.
This may be useful if you want to look for newer exploits, that are generally more likely to work than older exploits.
Rank
The rank determines how well the exploit works. Not every exploit works all the time, so it makes sense to give the user some indication what to expect. Here are the possible values and what they mean (taken from here):

Excellent: The exploit will never crash the service. This is the case for SQL Injection, CMD execution, RFI, LFI, etc. No typical memory corruption exploits should be given this ranking unless there are extraordinary circumstances.
Great: The exploit has a default target AND either auto-detects the appropriate target or uses an application-specific return address AFTER a version check.
Good: The exploit has a default target and it is the "common case" for this type of software (English, Windows 7 for a desktop app, 2012 for server, etc).
Normal: The exploit is otherwise reliable, but depends on a specific version and can't (or doesn't) reliably autodetect.
Average: The exploit is generally unreliable or difficult to exploit.
Low: The exploit is nearly impossible to exploit (or under 50% success rate) for common platforms.
Manual: The exploit is unstable or difficult to exploit and is basically a DoS. This ranking is also used when the module has no use unless specifically configured by the user.

Why is the scanner labelled "Normal" and not "Excellent"? Only the author knows.
Check
"Check" informs you if the check command is available. Simply put, check checks whether or not the target is (likely to be) vulnerable against the selected exploit. For example, the MS08-067-NetAPI exploit includes a check option, which allows you to verify whether or not exploitation is (likely to be) successful before attempting to exploit the target.
As you can tell, this only really makes sense for some exploits, and may not be possible with every exploit. For the scanner module in your example, it doesn't make sense - the scanner is its own check - so no check is available.
Description
This is a short, one-line description about what the module does. In this case, it informs you that auxiliary/scanner/http/ssl_version is a SSL/TLS version scanner for HTTP servers - which isn't all that surprizing. However, other modules may have slightly more mystifying names, such as exploits/linux/misc/hplip_hpssd_exec, so it's good to get a gist of what a module does. In this case, the description reads "HPLIP hpssd.py From Address Arbitrary Command Execution".
If you still don't know, then the info command will give you a more detailled information, such as:
Description:
  This module exploits a command execution vulnerable in the hpssd.py
  daemon of the Hewlett-Packard Linux Imaging and Printing Project.
  According to MITRE, versions 1.x and 2.x before 2.7.10 are
  vulnerable. This module was written and tested using the Fedora 6
  Linux distribution. On the test system, the daemon listens on
  localhost only and runs with root privileges. Although the
  configuration shows the daemon is to listen on port 2207, it
  actually listens on a dynamic port. NOTE: If the target system does
  not have a 'sendmail' command installed, this vulnerability cannot
  be exploited.

That should give you a good indication of what the module does and wheter or not it makes sense for you to run it.


Shouldn't GPG key fetching use a secure connection?

It depends on your definition of "compromise".  The main concern is privacy, for which parcimonie and tor are solutions, as noted below.

But first lets look at data integrity.

The notion of "end-to-end" security is most helpful when it covers the actual application you have in mind for the data.  Since the objects moved around by the OpenPGP HTTP Keyserver Protocol (HKP) are covered by signatures based on public-key technology, they can be checked by your application (e.g. gpg) itself.  It will establish whether the signatures are valid, whether they apply to other keys and people you trust, etc.  (Update: So gpg only (optionally) gets the certificates from the keyserver, it does not rely on any keyserver to establish the validity of the keys.)

For example suppose you're using gpg to check signatures on email.  If gpg tells you a given key is not known, you fetch it from a keyserver.  Perhaps your mail then tells you the key is known but not trusted, since there isn't a trusted path (e.g. leveraging wotsap) from your ultimately trusted keys to the one that signed the email (like this one). So you look at the signatures, and find the key of someone who is trusted by someone you know, and who trusts the given key and download that too.  If you end up with a path you trust, everything is great.  If someone mucks with the keys while you're downloading them, you either won't get a trusted path (due to broken or unhelpful keys), or (and this would be pretty unusual) you'll get another path that might or might not work for you.  The point is, though, that you still have to use gpg to check the paths, and evaluate the "intangibles" of the trust path yourself (how much you trust people and their understanding of signatures, etc).  But you always have to do that with PGP.  It is thus "end-to-end" in the sense that it is secured all the way from the person who made the signature, to your software which checks the signature, and your configured trust roots, and is thus pretty much ideal.

The security of the transport is not particularly important, and using TLS and the associated PKI and certificates would add extra complexity, cost and brittleness to the PGP keyserver infrastructure, without improving data integrity.  If someone messed with the transport, they could deny you service, or do something like a phishing attack, but you nearly always have to deal with those sorts of issues anyway.

See e.g. the "Security Considerations" section of the (expired, but presumably still useful) Internet Draft on the subject: draft-shaw-openpgp-hkp-00 - The OpenPGP HTTP Keyserver Protocol (HKP)

A much more significant data integrity concern would be the risk of being fed a carefully crafted "malware certificate" that can exploit a buffer overflow vulnerability in your gpg client, or something like that.  I haven't heard of any such exploits in gpg, but they have happened for SSL: yaSSL Certificate Processing Buffer Overflow Vulnerability - CNET.  This is explored more at What risks are inherent with connecting to an untrusted public key server?

Update:
A more problematic concern is privacy.  If you don't want people to be able to see what keys you are searching for, or to mess with your key transfers, using TLS would be an alternative.  But it doesn't protect you from the server knowing what you're interested in.

@teris-riel expands on the privacy concern: Imagine someone sends you a signed then encrypted email. Your mail client happily retrieves the key for the signature. Evan is watching the traffic and sees the key fly by. Now he knows 1) that you can read messages encrypted with the key he sent to, 2) that you did read that particular message, and 3) the approximate time you read it. If this kind of confirmation attack worries you, use hkps and Tor to get keys, and don't do it automatically. parcimonie is a tool that works to solve this problem.

And as a parcimonie implementation in bash notes: gpg --refresh-keys discloses your entire list of PGP keys to the keyserver you are using, as well as whoever is wiretapping your connection if you are using an unencrypted protocol such as HKP (which is the default for most setups). That is a bad thing.

So use something like parcimonie.

There are some alternative protocols, but finding servers for them which contain the keys you want seems hard:

Symantec's PGP Global Directory uses https.
LDAP, or LDAPS (over TLS) - And see PGP LDAP Keyserver Comparison.  But see also PGP: Public Key Servers by David E. Ross
RFC 4387 which provides an https option.  But I'm not sure how many servers for it there are out there.

See also

How should I distribute my public key?
Key Server (Wikipedia)


This is a common need and the usual approach is to do 3 things:

develop a schema that describes acceptable inputs and optionally outputs for each endpoint

If these APIs are using JSON or XML for their inputs and responses, and have consistent request and response formats per endpoint, there are schema languages for those formats.

If not, or if the composition of acceptable requests- what fields may exist or not exist, what kinds of values may appear, etc- requires some context and can't necessarily be generically validated, then this may be challenging.
introduce an API gateway into the architecture

API gateways are intended to live at the edge of the infrastructure, like a webserver, but to also provide for execution of complex logic, so they all include some runtime language integration.

Some open source options are:

apiman http://www.apiman.io/latest/
zuul https://github.com/Netflix/zuul
kong https://getkong.org/
tyk https://tyk.io/
wso2 http://wso2.com/products/api-manager/

Several of these have commercial support options.
Introduce validation logic utilizing the schema definitions into the api gateway for each endpoint.

The API gateways offer many other benefits beyond request/response validation that matter when exposing APIs to - needs like authentication/authorization, rate limiting, metering, metrics, white/blacklisting, caching, transformation- are also available.


Is there an added benefit to authentication within a part of an application, after authenticated into the main application?

I'll propose a rule of thumb which may help you with your decision:

  When switching from a lower privilege level to higher, make them login again.
  When switching from higher to lower, do not require another login.

Here's an example of how bank ATMs implement this rule. Consider these 2 scenarios:

You put in your ATM card, enter your pin, select "Withdrawal", choose your amount, receive your money, view the balance of an account.
You put in your ATM card, enter your pin, view the balance of an account, select "Withdrawal", choose your amount, enter your pin again, and receive your money.

The only difference between these scenarios is whether the withdrawal happens before or after the balance inquiry. If you begin your session with a withdrawal you are assigned the highest permissions, and therefore you can do an item of lessor permission afterwards. If you begin your session with a balance inquiry, you are assigned lower permissions, and then in order to perform a withdrawal (which requires the highest permissions) you must enter in your pin again.

Perhaps you can use similar reasoning when determining if your user should have to login again.


how to extract binaries from SOHO routers and other devices

Aside from the already-mentioned option of pulling and extracting firmware updates, most routers offer a command-line admin interface, available over SSH or even Telnet. Connect to this interface, and you'll be dropped into what is supposed to be a secure, restricted shell. In practice, the shell will almost certainly have some way to do command injection (for example, on some routers, running any allowed command followed by $(command) or even ; command will work).

Once you've got command injection, verify that you're root (quite likely). At that point, you can use common Linux commands (the device will have a limited command selection but you should be able to find what you need) to get a way to copy binary files. Extract individual binaries and/or entire volume images to your PC through that, and analyze them to your heart's content.

If you aren't root, you'll need to find a local EoP vulnerability on the router; these are common enough in Linux that old firmware will almost certainly have some, though you might need to compile the exploit for your specific platform. I've yet to see a SOHO router where I needed to do this; though.


What questions are useful to scope a mobile app pen test?

I found it rather important to say that not all apps are purely created with Java and XML, there are people who like to convert their website into an android app, in fact that's just a copy of their website displayed on 5" screen., not only because it's cheaper but also because it saves them time.
Some suggestions,

Is it a converted app? (in case it is converted from a webpage)
Which technologies has been used during the development process or in the app, such as HTML5 or javascript?


Is it possible to modify SSLStrip such that the client has an HTTPS connection?

No, to be able to perform that the attacker must have the private key associated with the certificate of the website (private key used to generate the public key in the certificate).  The client will send a challenge to the website during the SSL handshake and if it does not come back signed with the private key of the website it knows it is not talking to the website in it is trying to talk to.

The attacker cannot generate a different key-pair because the client has a CA certificate (in the browser or as part of the OS) that sings the website's certificate.  The certificate signed by the CA relates the domain of the website to a public key and only the private key of that specific domain (i.e. that public key) would be able to sign the challenge text correctly.

On the other hand, if the attacker can get hold of the private key of the website (to achieve which he would likely need to copy it from the website's servers) then he would be able to perform HTTPS to the client.

Yet, this is not an SSLstrip attack anymore, this would be a plain compromised certificate.  And, if the website discovers the compromise, will likely add its certificate to a database of compromised certificates.  For example the OSCP database which several browsers will check (of course the attack may be ale to spoof the OSCP request).

Another option is to fool the client (thanks @crovers).  If and attacker can make the client to accept a new root CA certificate, he can sign the domain with his own CA and provide that as a certificate instead of the real one.

This again is not SSLstrip, this is a form of phishing the user into installing bogus CA certificates.


Is there a way to answer security questions privately while in public?

You could standardize on all secret questions being number based.  Then, when the questions are asked, they could include a bit on the end to add or subtract some.

So for instance, the questions would be:

What is the last four of your social security number plus 11?
What is the street number of the house you grew up in, minus 2?
What is your birth year plus 13?

Anyone hearing the answers would hear only the numbers, without knowing the actual questions.  Each time the questions are asked, the numbers on the end could be randomized by the caller, so they would be different every time.  (For instance, the next time, the questions would be, "What is the last four of your social security number minus 7?, etc.")


A "client-based solution", as you mentioned, would be dependent on the service providing the DHCP leases. In the case of it being your router, you'll need to query the device for the systems it has issued DHCP leases for.

Alternatives

If you're looking for basic host enumeration tools (i.e. things you would use on a pentest to do host discovery), you can use the following tools:

fping -a -g <ip-range> 2>/dev/null
dnsrecon -r <ip-range>1
various nmap scans
nbtscan <ip-range> (For Windows hosts broadcasting netbios names)

Using a variety of the techniques above, you should be able to get a pretty accurate depiction of the hosts on the LAN.


How is generating payment Tokens secure in Mobile development?

You seem to have a misunderstanding about token creation, when you say you can create a token without having it be over HTTPS.  Token creation goes as follows:

Cardholder submits card over HTTPS to Stripe
Stripe stores the card number and associates it with a token which they generate
Stripe hands the token to the merchant (you).
From then on, you can charge the underlying credit card by telling Stripe to charge that token.

Step 1, where the card number is transmitted across the network, must be protected by HTTPS.  The token, while not as sensitive as the card number, is usually transmitted over HTTPS also.

When Stripe says

  we suggest that you also serve the page containing the payment form
  with HTTPS

They mean that your page which contains the form (or iframe, or link, or javascript) that leads to Stripe.  They're not talking about subsequent token transmissions when they say this (although, again, standard practice is to protect the token as well).

To answer your questions:

  Is it secure for token be created over HTTP and not HTTPS?

No.  Token creation requires card data be transmitted, which requires HTTPS as per PCI.  Remember, you don't create the token, Stripe does, and they're at the other end of the Internet from both you and your customer.

  If so, couldn't the user's card info be jeopardized (e.g collected or scraped) in this process?

Since #1 is "no" the "if so" clause doesn't apply.  (Yes, if you didn't use HTTPS, the user's card info could be jeopardized, which is why it must be HTTPS.)

  What are the best practices when dealing when mobile?

Best practice is to encrypt everything, on or off mobile.


What does the CSP require-sri-for directive protect against?

The HTTP Content-Security-Policy require-sri-for only aims to protect against developpers who would forget to add the integrity tag.

Frederik Braun, who claims to be the author of subressource integrity wrote on his blog :

  GitHub is one of the first big websites using Subresource Integrity and can thus defend against potentially bad Content Delivery Networks (CDNs). The tricky thing with SRI is that you have to include it for every HTML tag that points to a CDN if you want the security benefit. And then, of course, it happend that someone forgot to add this and people were sad.


How to make sure my web application is secured?

To be the one to make this comment: you can never be 100% sure.
But you can:

Use vulnerability scanners (credentialled and uncredentialled) regulary (every week?) to make sure public vulnerabilities have been patched and you have not accidentally opened your webserver up to the outside world. Try using OpenVAS or Nessus (or any other) for vulnerability scanning. Try using OWASP ZAP every now and then to see if you have any webvulnerabilities
Run the SSLlabs scanner on your site every month to make sure you are still up to date with encryption
Run your code through a source code scanner (can someone say which one is easy and good?)
Think of secure processes to run through when administrating your website. So how do you work with passwords and autorisations (I do not know if you have employees)
Take the OWASP testing guide and try to run through it yourself. Also look at the OWASP cheat sheets for administrating and developing your website and webservices
Hire a pentesting company once a year to do a real "once over" to see if you have vulnerabilities that you yourself and the automatic scanners do not have the expertise to find (mostly in business logic and more indepth vulnerabilities)

I am assuming here that you are not a security professional, so cannot do everything yourself. But I think if you make use of automated scanners and hire pentesters once a year you are as secure as you can be in normal circumstances. If you have no money for pentesters you will have to try to do most things yourself (OWASP testing guide is a real help!). If you have tons of money you should hire a security professional to constantly help in improving the security of your organisation.


Application control of HTTP content compression

HTTP compression is controlled by the webserver, you configure IIS/Apache/Other as appropriate and this sets the compression header which your browser understands and treats the content as accordingly.

BREACH is a vulnerability in applications that use HTTP compression, reflect some sort of user input and also reflect a secret, such as - as you say - a CSRF token. the attacker then takes advantages of differences in the response sizes to determine secrets. There is a good explanation of BREACH here

Simple mitigations include disabling the compression which or may not be practical depending on your application. As the compression is performed at web server level, determining when to compress in the application may be tricky, a simpler approach is to inject noise the response on pages which are vulnerable. A random string of random length injected into the response is a good countermeasure if you wish to keep compression enabled.


no matter how long it would take?

This is the thing about brute-force attacks: given enough time you can compromise everything. However, "enough time" may be longer than a human lifespan, or longer than the lifespan of the solar system. In your case, there approximately 80 possible characters, and 7 positions. This gives 807 = 20971520000000 possibilities. If you can try 100 tokens per second it would take you 6650 years to try them all.

Also, this token is a method of securing access to this song. Trying to bypass this may be against the law.

That said, I typically use the intruder tool in Burp Suite for brute-force attacks.


How authentication using md5 works in this ospf example?

Is this the result of a salt?

That's part of it, but the PRNG (link) is also part of the reason why you're seeing different values on there.

  After some quick queries in some online cracking websites (with
  rainbow tables) i was not able to reverse the hash

You better not be able to.  Cryptographic techniques like salting should defeat rainbow table attacks on the hashes.


Exploit user input being directly inserted into PDF

What you need to worry is

Whether the website sanitize the user input. So in case of XSS, malicious code will not be injected.
Reputation of the web services that generate the PDF file. Acrobat reader exploit code can always be injected into the PDF file.

This is better than worry about than learning all sort of PDF object that are exploitable by attacker.


Is it Safe to Send an Invalid Password Back to the Client?

When the credentials are wrong, the server sends you back a page containing the filled username and perhaps also the password. That should be done with https, and caching headers asking not to store it, but there's the possibility that the error page that was sent with the provided password in the source is stored somewhere (browser cache, an intermediate proxy…).

When there's an asynchronous login, the page itself is not reloaded, and thus this issue doesn't happen.

With a login form, you pretty much always want to blank the password, as the user will have to retype it anyway since it was wrong (and is unlikely to know which was his typo).

The debate on whether to-blank-or-not-blank the password field usually arises  when dealing with the registration form. There it is likely that an unrelated field is rejected (eg. username taken) and the user needs to provide a new username (which may turn out not be available, either) and the password and password confirmation. That makes an unpleasant UI. And there there are different opinions on which should wine.


XSS triggered but chrome didn't show popup. What exactly was going on?

The XSS auditor can be triggered even if your payload isn't working, and sometimes even if there's no XSS vulnerability at all!

The XSS auditor just looks at the request parameters to check if there's a match with a part of the response.

To understand why your payload isn't working, disable the XSS auditor and look at the HTML source / developer console.


booting from linux CD and visiting https website only

Yes, this is a good, pragmatic approach that should provide a reasonable level of security against many threats that he might face.  It is not perfect (for instance, it doesn't prevent the sites he visits from including external resources over HTTP), but it's probably good enough for most purposes, including, e.g., online banking.

If he uses Firefox, if he can arrange that the copy of Firefox on his bootable Linux CD has the HTTPS Everywhere extension installed, that would be a nice addition.  HTTPS Everywhere is intended to help direct you to the HTTPS version of popular sites that are accessible over HTTPS.  But this may be unnecessary, depending upon his habits.  For instance, if he only views one or two web sites, and is careful to always type "https" into the address bar, then HTTPS Everywhere may be unnecessary.

If he also needs to protect his privacy or anonymity, he might consider using Tor's Live CD, which comes bundled with Tor for anonymity.

P.S. See also the question on Secure Linux Desktop.