Safety level of encrypting data with BitLocker?

In theory as long as you keep the encryption key separate from your device and it is not stolen also you should be fine.
However not so long ago a security researcher found a way to bypass bitlocker altogether on domain joined devices.
The biggest problem with encryption is not the algorithms but the implementation.
Since Bitlocker isn't open source it has never been audited by the community so we can't know if there are more "accidental" backdoors.
You could say that bitlocker is good enough and if someone does steal your device it's probably not going to be the NSA. I'd rather go with open source solutions that have been verified by the community such as veracypt (the replacement of truecrypt) for instance.  Here is a very good read on the whole topic.


Is AES-256 not the best decision for mantaining performance in a Datalake?

So in the benchmarks you've linked, the difference is about 40%. If that is too much for your purposes because it would cost too much server capacity, then it's too much. If not, then it's not too much. If you want to know if it's too much for a user, you could do a quick blind test and see if they even notice the difference in practice (if you can't use the real code, just make a dummy site where the operation is 40% slower).

You say you don't think those benchmarks apply to each language, and you're right, but they are ballpark accurate. Save for bugs, another language is not suddenly going to be 140% slower. Because of that, other benchmarks won't make a difference in your decision. And if 35% is acceptable but 40% is not, then you should really benchmark on your own hardware with the software that you will actually be using.


How to show your work to potential clients as a pentester?

What you are talking about is "work product" (the pentest reports). There are lots of industries where someone cannot show their work product to another person to show their expertise. A cashier cannot show another employer their work product, because there is nothing to show.

What you are trying to figure out is what to show instead of your work product. That's actually quite easy.

Referrals
Testimonials from previous clients
Testimonials from co-workers/employers
Certifications (some people will flay me for this suggestion, but it helps support actual work you've done - certifications should confirm your expertise and not be the sum total of your expertise)
Performance in competitions
Work product in adjacent areas (CVEs, bug bounties, things you've coded, books, etc.)

You want to show, not your main work product, but your skills in adjacent areas that reflect your skill and expertise in your main work.

The easy way to do this? Get more public with your technical work (CVEs, competitions, CTFs, etc.) and create materials to help potential clients, whether they hire you or not. Books, a blog, anything to reach out to customers to help them but not sell to them. If you can help as a hired pentester, then you can help as a provider of general advice. Do that, and you develop trust. When you reach out to prospective clients, you can give them your free material, whether they hire you or not.

When you can't show work product, you need to have trust and reputation.


Is the pfx that contains ssl the same pfx that is used to sign an application

If the PFX file contains your private key and is then shipped with your application, then all machines that have your application have your private key. Unless you are confident about the security of these machines, then you have compromised your private key.

In general, you should not require the servers private key/PFX file to be sent to clients. Although you may need to send private keys to clients if your server is authenticating the clients using the certificates (mutual SSL). In this case you would need a unique private key/PFX per client.


How are large tech sites such as LivingSocial, Zappos, LinkedIn and Evernote hacked?

I don't understand how these database tables are accessed. Surely it is not SQL Injection, as that should be a thing of the past with prepared statements,

Ahhh assumptions.. Have you seen the OWASP Top Ten project? SQL injections have always been a constant source of security issues.

  I cannot see how changing any session state would effect the application as Unit Tests would have already picked this up

Have a look at OWASP Top Ten again... Poorly implemented session state management have always been a constant source of problems as well...

  I cannot imagine that hackers would easily be able to gain root access to the machines which be locked down with a SSH key.

Again, assumptions. There is a whole bunch of vulnerabilities out there that will allow privilege escalation into root. This is especially true if you are running old, unpatched or misconfigured systems. Have a look at exploit-db and take your pick...


Does serving Tomcat via Apache Webserver improve security?

My vote would be number 3, with number 2 as a close second. I suppose it depends on the rest of your infrastructure. To my knowledge, AJP doesn't support encryption between hosts.

Number 3 allows you to implement an N Tiered architecture. Ideally the Apache server would be parsing/URL filtering for malicious traffic and not blindly proxying all requests to the Tomcat server.

There is a fairly decent article (with comments) here: https://communities.bmc.com/community/bmcdn/bmc_atrium_and_foundation_technologies/bmc_remedy_ar_system/blog/2013/12/20/the-pulse-why-should-i-use-a-web-server-to-front-tomcat

Even with that being said, there still seems to be some confusion as to whether Tomcat is a Webserver, an Appserver, or both! There are conflicting answers for this question.

If it were me, I'd still choose number 3 based on the above.


Maybe strings can be of help? With the -eb parameter it will extract UTF-16BE strings.

As for Russian characters not being found, I am not aware of a tool that will find them directly. But, Python to the rescue:

russian_str = u''
f = open('fakeslack', 'rb')

while True:
    c = f.read(2)
    if c == '':
        break
    if c[0] == '\x04':  # russian chars start with 04
        russian_str += (c[1] + c[0]).decode('utf16')  # big endian
    else:
        if russian_str != '':
            print(russian_str)
            russian_str = ''

This works for me on a fake slack file that I generated by pasting some words from Russian Wikipedia between some English words and whitespace:

$ cat fakeslack
foobar
fewufew
fweu
ncd
Википедию кораблях  fweufweАйоваnwefwe
$ recode utf8..utf16be fakeslack
python ru_strings.py
Википедию
кораблях
Айова


Attribute-based access control standard definition

There are several places where you could find a "formal" definition of abac. One such place is NIST, the National Institute of Standards and Technology. They have a dedicated site on ABAC.

Their definition is as follows:

  ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object) actions and the environment relevant to a request. Attributes may be considered characteristics of anything that may be defined and to which a value may be assigned. In its most basic form, ABAC relies upon the evaluation of attributes of the subject, attributes of the object, environment conditions, and a formal relationship or access control rule defining the allowable operations for subject-object attribute and environment condition combinations.

In fact, ABAC uses two fundamental building blocks:

attributes (key-value pairs)
policies (or rules)

Like the definition says, attributes can be about anything (users, objects, environment, context, and more). Generally attributes relate to the grammatical function they play in a sentence e.g.

  Managers can view documents they own

Translated, it becomes

  A user with role == "manager" can do action == "view" on object of type == "document" if user.name == document.owner

The standard implementation for ABAC is xacml & ALFA. There are several open-source implementations (AuthZForce) as well as commercial (Axiomatics - which is where I work)

Attributes can be typed (string, integer...) and multi-valued (e.g. you can have multiple roles). XACML / ALFA define the policy language to express ABAC. XACML also defines a REST/JSON profile to POST authorization requests and receive responses back.

David


How can I track someone logged in my gmail account over imap?

Yes if you don't have two-factor.

No if you do.

If you enable two-factor, then the IMAPS connections require a generated app password which you can only get by logging into your Google account profile and generating online.  You can't set these passwords, but you can leak them so be careful not to store them beyond what the email client requires to function.

Disabling POP and IMAP is the best mitigation.  If you really need IMAP then two-factor is a good mitigation. Two-factor is good to enable either way.


Is it secure to use unique prefix for each dataset, instead of using IV (in AES)?

In your case, correct. You do not need a random IV. The combination of user_id, ssn, and your Key is globally unique, so the attacker will not be able to find duplicates from a secure algorithm. (i.e. AES-128 or higher)

Edit: IVs should always be random. While in the OP's case it may not be that important, it usually is, and is easy to implement, so use random IVs. See comments.

It's worth noting that you are not using a chaining algorithm because the amount of data you are encrypting is so small. This reduces what you have to worry about. The purpose of the IV is to make sure the first 'block' is unique, and the purpose of the Chaining Method is to make the remaining blocks appear random so there is no discernible pattern in long data.

But your data fits into one block (128 bits for AES-128) so that is not necessary.


Is it okay to add self-signed certificate on trusted store in this situation?

If I correctly understand, you want to build a correct SSL connection without having to buy a certificate to a third party well known provider.

As you said that you could know all clients and pre-install certificates before first communication to server, it is perfectly fine. Simply if you directly use self signed certificate you could lead browsers (and users) in various corner cases, that you could easily avoid.

My advice would be to build a mini CA (openssl comes with all you need for that, include tutorials):

you create a self signed cerficate that will be used to signed auxilliary certificates and store the private key in a secure place
you pass it offline to you clients, and ask them to install it as a root certificate (all root certificates are by definition self signed)
you create a server certificate that you sign with the self-signed certificate and use it normally.

That way all browsers will process smoothly a standard certificate chain. As a bonus, you could even publish an initialy empty Certificate Revocation List, that you could later use if you needed to revoke one certificate.


Does a sudden ERR_CERT_COMMON_NAME_INVALID maybe suggest a man-in-the-middle attack?

typing 207.244.80.166 into Chrome loads this error message:
  Error: "Subject Alternative Name Missing" or NET::ERR_CERT_COMMON_NAME_INVALID or "Your connection is not private"

This is the expected  behavior. If you specify the IP address instead of the hostname in the URL it will expect that the site returns a certificate which matches this IP address. But, the certificate returned for this site is not for a specific IP address but only for a hostname, i.e. it covers rt.com and *.rt.com.

"Subject Alternative Name Missing" is slightly misleading since the certificate actually has subject alternative names (SAN). Only, it has no SAN for an IP address but this is expected since you've entered an IP address in the URL.

  Gosh, could this mysterious error message that just came out of nowhere be explained by a man-in-the-middle attack?

There does not need to be any man-in-the-middle attack involved to get this kind of error. You get the same problems with other sites when just using the IP address in the URL instead of the hostname. Try for example https://104.102.5.46/ which uses the IP address for www.whitehouse.gov and you'll see that the problem is the same.


Firefox: Yes. Sign your .xpi file using xpisign.py (with a certificate from a trusted issuer, such as Verisign).
Integrity: Firefox will report a corrupt add-on if the hashes do not match.
Verification: The user just needs to see if the add-on installation prompt says "Name of extension (developer name)" instead of "Name of extension (author not verified)"
Chrome: Yes. The .crx file is a zip file preceded by a public key and zip content's signature.
Integrity: Chrome will abort the installation and show CRX_SIGNATURE_VERIFICATION_FAILED if the extension's signature is invalid.
Integrity: (alternative method) Cut the headers from the crx file, and extract the public key and signature. Check if the signature is correct.
Verification: Check if the public key matches with your key.
Opera: The .oex file (=a plain zip file) cannot be signed.
Opera 15+: The .nex or .crx file has the same format as Chromium's .crx file.
Safari: You can only install a Safari extension if it's signed with a key which matches a certificate which is signed by Apple. More info on signing .safariextz  files.
Integrity: Safari refuses to install invalid extensions.
Verification: Extract the certificates from the extension using xar -f path/to/name.safariextz --extract-certs output_dir. Then check if the first certificate (output_dir/cert00) is identical to the developer's certificate (or at least check if the properties (such as the Developer's ID and name) are plausible).
Internet Explorer: The "extensions" are .dll files (BHO, accelerators, ...) which can be signed, using Microsoft's signtool for example.
Verification: Look at the properties of the file, and check if the signature is deemed valid by Windows.
(NPAPI) plug-ins: The plug-in's binaries can be signed.


How much does a GET request over HTTPS reveal to an eavesdropper

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent.

No, this is not a HTTP CONNECT, it is a TCP connection request. The HTTP CONNECT method is only used if you are connecting over a HTTP proxy and the proxy server's certificate is not trusted by the client browser. This will make future requests travel over the proxy as pure SSL data (encrypted), rather than as HTTP requests (decrypted on the proxy and then reencrypted for the destination journey).

  When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet. Everything else is encrypted. please do correct me again

Almost. They can see source and destination ports and IPs, and if SNI is enabled they can see the destination domain name.

  So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

Yes, for these purposes. A MITM would not see the path or query string parameters on the URL, although as you mention it is easy for these to leak in places such as browser history, the logs of any trusted proxy servers (e.g. a proxy in a corporate environment that is trusted by the client machine) or possibly in the referer header.


How to choose between password derivation or encryption?

I have used deterministic password managers (pwdhash, what you call password derivation) for a long time and I wouldn't advice anyone to use a deterministic password manager. I also wrote a blog post about this, but I'll summarize my main issues here:

It is hard to determine the account to derive the password for. Maybe you want to use the same password for wikipedia.org and for wiktionary.org, or live.com and microsoft.com. Determining the account to use based on the domain name is pretty hard.
It is hard to conform to password requirements. Some sites don't allow passwords of 20 characters, and some sites require your password to be 20 characters. How is your derivation function going to handle that?
It is hard to change the derivation function. Once you use the derivation function, you depend on it for all your passwords. You can't increase the complexity or increase the length of the derived passwords or anything, because then you can't login anymore on all sites.
If you use some site to derive the password, such as lesspass.com or pwdhash.com, you supply that site your master password every time and that site generates your account password. This creates an enormous single point of failure. If that site is compromised all your accounts are compromised.

The main "advantage" is that a deterministic password manager doesn't keep state. However, it becomes increasingly easy to store state somewhere on the internet, either in a file in Dropbox or through some cloud service.


Cross-Domain Request is a CSRF Attack? (CORS)

Was this Cross-Domain HTTP request essentially a CSRF attack?

Essentially, yes, but only because you specifically disabled the checks that should have prevented it.

If yes, it happens because there is a CORS misconfiguration and there isn’t the CSRF Token? What happens if it has a Anti-XSRF Token?

There are a number of additional factors to consider:
First, not all requests are XHR requests, and therefore are not subject to CORS. The malicious page can host an plain old <form method="post" action="https://yoursite.com"> which can submit arbitrary payloads to your server (without allowing the attacker to read the result), necessitating a CSRF token. Modern browsers make this somewhat unnecessary by supporting the SameSite attribute for cookies, but not all browsers support SameSite, and some users will be on browsers that lack SameSite support essentially forever. So, CSRF tokens are still important to prevent cross-site form submissions.
Secondly, the HTTP verb matters, and can be considered an additional layer of defense. As you state...

I read that CORS and SOP can’t block a CSRF attack, because the policy prevents only to access to the response on the request, but the HTTP request works anyway.

What you describe only applies to GET requests. However, GET requests do not use a CSRF token in the first place. As long as your service correctly only uses GET for idempotent requests with no side effects, the GET request can succeed, and there is no danger as long as the malicious page is prevented from reading the result.
CORS protects other methods like POST/PUT/DELETE (that do cause side effects) with a preflight OPTIONS request. If that preflight request fails a CORS check, not only is the attacker prevented from reading the response, the actual POST request will not happen, so there is no response to read in the first place. The browse will not actually perform a POST to your service if the OPTIONS request fails.
So, in the usual case where a CSRF token is relevant (PUT/POST/PATCH/etc) a CSRF token would have prevented the CORS misconfiguration you describe from allowing arbitrary XHR and non-XHR requests from malicious domains, but only if combined with an old browser or a SameSite misconfiguration.

If CORS and SOP can’t block a CSRF attack, the CSRF attack could work also if the web server target is not vulnerable a CORS misconfiguration?

No. If CORS were correctly configured, and your service didn't use GET incorrectly, CORS would allow the (safe) GET request but prevent the attacker from being reading the result, and it would prevent POST/PATCH/etc request from being made at all.


How to protect against leaking Google Drive synced files from a stolen laptop?

You could only sync specific folders from Google Drive, i.e. the ones used most often, while the rest are only available via online sign-in. However, it sounds like that is not what you are looking for, and it may be difficult to enforce.
Tighter access control, and even using multiple accounts per person. Mobile use may not need the same files as office use.
Full Disk Encryption is probably the best option here. Keep in mind that if the laptop is stolen while unlocked then the security will not be in effect.

While it's not actually necessary to encrypt the entire disk, I think that will be easier to set up.

My favorite solution from a security standpoint is not to store the files locally at all.

Perhaps providing a means to remotely sign in to in-office computers from the mobile laptops. Unfortunately, such screen mirroring requires quite a bit more bandwidth.
Migrating to cloud-based solutions, i.e. Google Docs and Google Sheets, or other services that are cloud-based and only accessed through the browser would be the best solution. I'm not sure what kind of documents you are currently dealing with so this might not be an option.

Obviously making sure that sessions are invalidated (signing out) when the device is stolen could be important, as well as detecting the theft to begin with.

Fortunately, with Full Disk Encryption, once the device is shut down, and assuming you have a sufficiently long Password, it is fully secure.

Many devices come with a Kensington Lock Slot which can be used to physically tie the device to its vehicle or something. Obviously many attack options are still available, but least it definitely will increase the amount of time needed for theft. (since simply snatching the laptop is no longer possible without breaking something first)

Finally, it is possible that there is some utility out there which provides filesystem-like access (i.e. a mounted drive, e.g. SFTP or other solution) without actually syncing the file itself. However, I'm not familiar with these options.


Does the Windows Surface RT or Pro (Windows 8) support local encryption of Activesync data?

The Surface Pro runs Windows 8 Pro and has a TPM, so in theory at least, you should have all the available security features of any Windows 8 laptop, including BitLocker.


Where does last 4 bytes of hmac go in wpa2 mic?

It's supposed to be "negotiated" but the size of MIC is fixed to 16 octets, so independently from the algorithm used eventually it'll be truncated.

  11.6.3 EAPOL-Key frame construction and processing

  [...] EAPOL-Key frames are constructed and processed according to the AKM
  negotiated at association time. The negotiated AKM determines what
  algorithm is used to construct and verify a MIC, the size of the
  MIC, and the algorithm used to wrap and unwrap the Key Data field.

Table 11-9 - Integrity and key-wrap algorithms

So, they're discarded:

  11.6.2 EAPOL-Key frames

  HMAC-SHA1-128 is the EAPOL-Key MIC. HMAC is defined in IETF RFC 2104;
  and SHA1, by FIPS PUB 180-3-2008. The output of the HMAC-SHA1 shall
  be truncated to its 128 MSBs (octets 0–15 of the digest output by
  HMAC-SHA1), i.e.,
  the last four octets generated shall be discarded.

Taken from:

Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)  Specifications. (IEEE Std 802.11 - 2012)


How might one verify that the POWER9 CPU does not contain an AMT-style subsystem?

A lab could theoretically decap the chip and analyze it, and any large, complex subsystem inside would not be able to hide from that (although you could not verify that it matches the open spec). If there's something undocumented that functions as an actual backdoor, then it would, by definition, be hidden. There are endless possibilities for embedding a backdoor in a complicated architecture like POWER9. For example, setting a couple registers to magic values that are unlikely to be guessed or occur naturally and then running a particular unprivileged instruction could trigger the elevation to supervisor mode. It could even be designed such that vulnerabilities worse than Spectre and Meltdown are "accidentally" possible, providing plausible deniability in the backdoor.

In regards to the specific capabilities of the CSME or AMD PSP, you can verify that POWER9 lacks a few of those features. For example, the CSME has access to many network cards, and to the on-board gigabit Ethernet system (Intel GbE). This requires the PCH be hooked up to the network card in a particular way that may be unique to the x86 architecture. You should be able to verify that, for example, the CPU cannot directly control the network card in any way that is not possible through the interfaced used to connect to it (e.g. PCIe). You should familiarize yourself with the system's architecture, as it is quite different from systems that descend from IBM-style x86 PCs.

While I don't know if the AMD PSP can do this, server systems with AMT can keep the coprocessor powered up even when the system is off, as long as it is connected to the power. It is trivial to detect if this is the case with an arbitrary computer by measuring power draw while the system is off. It is trivial to verify if any coprocessor is exposing itself automatically to the network by seeing if the networking card has a new MAC address. This assumes they are on by default.

But what is the actual risk? I would say it is very low. AMD PSP and Intel CSME are designed to make the lives of system administrators easier, even if they come with security downsides. As such, it makes little sense to keep them secret and undocumented. The only reason they would be secret is if they are an intentional backdoor, in which case they need not manifest themselves as coprocessors, and could instead be implemented as a simple but fatal security "bug".


Is a full name and address all that's needed for identity theft?

How much is needed in order to perform "identity theft" largely depends on what you're qualifying as "identity theft". Regardless of this, it also depends upon what a given service provider requires for identification & authentication when someone contacts them for service on an account or to open new accounts.

Sometimes, name and address are indeed all that's needed. Sometimes, it's more. Sometimes, it may arguably be even less.

As for jump-starting identity theft, you don't even need that much. Just a person's first and last name can be enough. For some publicly-searchable databases - government-provided ones, no less - that's all you need to look up records which will contain ridiculous loads of additional PII. You might have a hard time nailing down a particular individual by name alone if theirs is common, like "John Smith". But it's a pretty fair bet that you can easily find whatever you want on a (hypothetical) "Joaqim Sikowicz" without knowing anything else about them.

As a particular example, I recently had to search for certain records regarding a traffic incident. Using only a person's first and last name, and a government-provided, publicly-accessible website that requires no registration, I was able to find:

Full Name (First, Last, Middle, Suffix)
Physical Address
Date of Birth
Telephone Number
Driver's License Details (Number*/Class/Expiry)
Physical Description (Race/Gender/Height)
Vehicle Description (Year/Make/Color/Style)
VIN
License Plate (Number/Expiry/State)

*-About the Driver's License Number, it's worth noting that these can often be simply derived from other trivially-obtainable PII. A quick Google search will turn up several sites where you might be able to do this with as little as: Name, DOB, Gender.

Also be aware that there are (or at least appear to be) zero restrictions against asking for one's SSN over the phone. I've had it done to me several times. Usually this is during a first-time account setup, but occasionally it's also happened for verification purposes where I have a pre-existing account. Where there's already an account established though, it's generally more common to just get asked for the last four digits.


How do I securely dispose of a removable USB storage device from within an office?

You can wipe it software wise first: dd if=/dev/zero of=/dev/sda. Securely wiping it software wise will take time tho.
Don't put it inside a microwave. Also water will not help 100%.
Your company's house keeper will probably have what you need. If the memory chip is physically damaged beyond repair, it will be impossible to salvage data from it. Some suggest beating it with a hammer to pulverize it. Others suggest using multiple drill bits to drill into the memory chip, essentially turning it into a powder. I suggest driving a nail inside it, makes less of a mess.


Ransomware doesn't change file extension after encryption

Is this possible?

Of course it is. It doesn't have to change the filenames at all. It just encrypts the content.

  Is there a mechanism to hide the extension? Because all files seem to be normal in that sense.

Yes, you could name it foo.txt.enc and then enable the "Hide extensions" option in Explorer. But as I mentioned above, it doesn't have to change the extension at all.


SSL/TLS has a very specific on-the-wire format for data: data is sent as records. Moreover, at the start of every connection:

The client talks first.
The client sends a "handshake" record containing a handshake message of type ClientHello.

So the very first byte from the client will be 0x16. It is then followed by the protocol version, which will be two bytes: 0x03, then a byte of (normally) value 0x00 (for SSL 3.0) to 0x03 (for TLS 1.2). Then the record length as two bytes. Within the record payload is found the handshake message header: a byte of value 0x01 (type for a ClientHello) followed by a three-octet length.

At some point, I had used a multiplexer for SSL and RDP on the same port: since the RDP connection begins with a byte of value 0x03 from the client, while the first byte of SSL is 0x16, so I could write a simple program which forwarded the data to either the Web server or the RDP server, depending on that first byte.

Not all DPI systems are sophisticated, and some can be fooled by applying variants of the protocol. For instance, the client can split the ClientHello message into several records, and possibly begin with a long stream of empty records. Some server implementations will actually tolerate an initial sequence of a thousand alert messages (of type "warning") which may evade the DPI system scrutiny in several ways:

The DPI system may expect a first byte of value 0x16, and deem it non-SSL if any other byte is sent (e.g. a 0x15 for an "alert" record).
The DPI system may expect the ClientHello to be contained within a single record, without fragmentation, and thus not recognize the SSL handshake.
The DPI system may expect the ClientHello within the first packet of the TCP connection, and all the extra empty records or alert record may push the ClientHello arbitrarily far into the TCP connection.

The trick here is to find variants which are accepted by SSL server implementations (who themselves have some more-or-less arbitrary limitations) but are not covered by whatever DPI system you are trying to hide from.

(If unsure, try to implement a custom SSL library -- for learning, not for production use, of course. This will teach you a lot of things on the details of the protocol.)


PCI-DSS Is the infrastructure really in-scope?

PCI-DSS only applies to computers and systems that handle PCI (Payment Card Industry) information.  If it is handled by a third party and you are only given a receipt token, then no PCI data is being handled by your system and it doesn't fall under PCI-DSS.


is sameSite attribute redundant on httpOnly cookie?

No, HTTPOnly does not mitigate CSRF attacks...You do indeed need SameSite for that.
What HTTPOnly does is to protect your cookies from being extracted and abused by an attacker who has found an XSS vulnerability on your website. SameSite on the other hand, prevents them from being sent along with requests from different sites, which can occur without the attacker ever having access to the cookies. This doesn't eliminate the need for CSRF protection in your application as browser support for the SameSite attribute is currently limited and the RFC is still in draft status, but setting it may be useful as a defense-in-depth measure.


What parameters to check to say that a computer running Windows is slow in responding because of infection?

I came across this interesting patent titled "Network-based infection detection using host slowdown"

I quote from the abstract of this patent:

  Host malware (or change) may be detected by (1) receiving baseline set of response time information for each of one or more transactions involving (A) the host and (B) at least one peer of the host, (2) determining or receiving a later set of response time information for each of the one or more transactions involving the host and the at least one peer of the host, and (3) determining whether or not host slowdown has occurred using the baseline set of response time information and the later set of response time information. The execution of a host malware (or change) protection policy may be controlled using at least the determination of whether or not host slowdown has occurred.


They were hoping the textbox submitted data to a sql server and that the data was not filtered/sanitized. 1=1' is a common method for testing for sql injection. The x || ping -n 3 127.0.0.1 & request is used for testing for shellshock vulnerability.

Answer to comment below:

By filtered/sanitized I mean using a method such as htmlspecialchars. I made 2 scripts especially for this answer. I have made a html and a php script that will demonstrate xss. Here is the html file.

  <form name="form" action="https://localhost/poc.php" method="post">

Test Form

  <input type="text" name="agentid" size="20"/>
  <input name="submit" type="submit" value="Submit">

  </form>

And here is the php file ("poc.php")

  <?php

  $test1 = htmlspecialchars($_POST['agentid'], ENT_QUOTES);

  $test2 = $_POST['agentid'];

  echo 'this is not vulnerable
';

  echo $test1 . "
";

  echo 'this is vulnerable
';

  echo $test2;

  ?>

Go to the html page and type XSS in the text box and hit submit. You will see a link on the webpage. However you will notice the link will only be under the text that says "this is vulnerable". Take a look at the webpage source code and you will see one result is sanitized and the other is not.


How to verify a x509 certificate from Apple on a Ubuntu server?

You need to update your root certificate store as in this post:
https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate
If I read your question right...looks like you have a copy of the cert?


How is compiling a program from source more secure?

It's harder to hide a backdoor in source code than in a binary. Someone could easily add a bunch of code before compiling a binary, but leave the extra code unpublished. If you build it yourself, then you can be fairly confident (outside of a compromised compiler, or network commands in the makefile) that the code you downloaded actually reflects what is in the binary.

In theory, at some point in time every line of code in Chromium, Linux, Firefox, etc. has been looked at by at least one person. Furthermore someone definitely looks at every change made. If the source code was ever non-malicious, it would be difficult to make it malicious.

I doubt very much that someone has disassembled the binary executable and matched up the assembly to the source code. It would be comparably easy to add malicious behavior to a distributed binary file with nobody being the wiser, especially if builds are not reproducible.


What security risks are involved with sending data over the internal network on Rackspace Cloud servers?

Then the risk of getting sniffed is low. You could do some test to see if what they are saying is true. If you really trust rackspace you can send data unencrypted. If your data is really critical or sensitive ... Encrypt it anyway just in case ;)


I agree that this isn't the best wording. Essentially, it means that there are unusual circumstances in order to exploit this. In the specific case of this bug, you have to get the user to connect to a malicious server under your control, or Man-in-the-Middle a connection to a legitimate server.

The vulnerability is a simple stack overflow on the version string which the server replies with. The client expects that the server will only reply with strings shorter than a fixed size, and then copies the entire string into a fixed-length buffer. If the string turns out to be larger than the buffer, it copies over the end, corrupting the stack.


Can I be attacked if I have a shared windows folder in a public network?

It depends on what permissions were set for the share folder.

If they had write access, your biggest concern is them putting a malicious file in that folder and fooling you into running it or getting another program set to run or open things from that folder to run it (hopefully you haven't set up something like that). They could also have modified a file you already trust in that shared folder in order to compromise something the next time you open it.

If they had read access only, your biggest concern is information disclosure depending on what you had in the drive.

Of course they could have done something to try to get you in trouble too like place some illegal content in your shared folder, but you would have noticed that.

Unless some vulnerability is found in the windows file and folder sharing protocol that you don't have patched, you don't have to be concerned with too much else.


First, there is the Endorsement Key (EK), an asymmetric Key. Each TPM owns a unique and identifiable EK. As it is unique and identifiable, we can clearly see privacy issues.

So the TCG created the AIK. An AIK is another key pair generated by the TPM, which will be signed by the EK. One can create multiple AIK. For an AIK to be used, one need to send the signed AIK to a privacy CA (Certificate Authority). Last issue, is can I trust the CA? If not, one can use Direct Anonymous Attestation (DAA), which will prove the keys used come from a valid TPM through a Zero-Knowledge-Proof.


Security of the Indian AadhaarPay fingerprint based payment system?

I had this exact same doubt a few days back. But it's not possible to hack it in the way you've described. Since biometric data is encrypted, a man-in-the-middle attack is not practically possible.

But the problem is with manipulated biometric scanners. Aadhaar fingerprint scanners encrypt the fingerprint data before sending it over or even processing it. What can be done is, have a engineered scanner which does not encrypt the data by default. So one can store of the data .

It is up to the device which connects to the Aadhaar API to verify the validity of the fingerprint (By checking finger temperature, contour, etc. to prevent masquerading with fake prints). So if the POS device is manipulated, it can send perform as many transactions as it wants with the saved fingerprint data.


Disable SSLv3 system-wide for all clients?

Its possible to make changes to the TCP/IP SSL levels, but not really considered a policy per say, You might be able to use a deployment service to make the changes using AutoIT (I make company wide changes with this as my deployment asset.


Can I use a VPN to disguise internet traffic at work?

PPTP is not secure How can I tell if a PPTP tunnel is secure? If you want to browse the Internet without being monitored then use a program like OpenVPN. Please see the comment below your question as it is important.


As with many things in security, it depends. It depends on the risks of not nuking it weighed against the risks of nuking it.

If you want to "stay safe", then the obvious answer is to nuke it. You don't know what you don't know.

However, if the risks of not nuking it (hacker using it as a base of operations and able to read all data) are lower than the risks of nuking it (loss of unrecoverable data), then you should not nuke it until you can mitigate the risks.

What I'm guessing is that you don't want to go through the time costs of nuking it, and you are looking for an excuse not to. That's valid, too! If your time is more valuable than the disclosure of the data to the public and the potential impact of a hacker camping on the machine, then the cost/benefit analysis is clear.

If you are looking for professionals to tell you, "meh, probably nothing happened" then I'm not sure anyone here would take the risk to tell you that or be qualified to make that call.

You had unpatched vulnerabilities for 1 week on average over a 3 year period. There are no known indications of compromise, but you might not be qualified to assess that. That's a lot of unknowns to play with. How lucky do you feel?


Should you be able to reset a password without verifying the email address first?

Leaving access to your phone while logged in to a service is without doubt a security breach, but I also see a few screw-ups from the part of Instagram here:

Not asking for the password when modifying the email address associated to the account
Sending the verification for the new email address to the new email address, instead of the old email address (or both old and new addresses)

Point #1 should be implemented in any environment which is minimally security-aware.  If not implemented, point #2 serves to mitigate this kind of attacks.


This answer is 64.7% opinion.

TL;DR: A port sweep looks for specific port(s) across multiple hosts.  A port scan enumerates any ports to be found on one or more hosts.

Some people use "port sweep" to describe a port scan that is focused on a specific port across a wide number of hosts, rather than on determining the open ports for some number of hosts.

An example:  imagine a new PostgreSQL flaw is found which permits compromise via the network listener.  You will quickly see scans, some of them Internet-wide, testing port 5432/tcp and nothing else.  This is a port sweep - a broad "sweeping" scan, targeted tightly to finding a vulnerable service, anywhere it can be found.

A sweep is not limited to one port.  Let's say that a flaw was exposed that impacted PostgreSQL and MySQL equally; you will see scans which hit both 3306/tcp and 5432/tcp, but nothing else.  However, the fact that it's focused on finding a discrete number of specific issue-related ports makes it a sweep.

Finally, a "sweep" may be used as a host detection method.  You can sweep for limited "likely" ports (80/tcp, 443/tcp) to see if anyone is there, and then go back to do full port scans against hosts that the sweep found to be alive.  This is common for things like the Internet where smart people disable ICMP ping.  It would take to long to do full port scans against a block with potential dead IPs, so the sweep is used to narrow the scope of the scan.

By this definition, the contrasting "port scan" is a full-spectrum attempt to enumerate all open ports (or at least a reasonably ambitions subset) on host(s).


Would placing a hardened virtual machine in a VPS provide more security?

Whether using a VM is more secure or not depends what you are protecting yourself against. If you fear that DigitalOcean may be trying to spy on you, illegally gives access to your system to hackers, or many other malicious activities, there's little you can do to protect against it. No matter how secure your VM is, they control the hardware and OS that it is hosted on. So they can install keyboard loggers, steal private keys and passwords from memory, etc...

On the other hand, if you're concerned that DigitalOcean monkeyed with the OS and somehow made it less secure, then running on a VM might help. It will depend whether whatever they did is still vulnerable when a VM is being used. For example, if they made some mistake that includes malware that allows a remote root shell on your VPS, then there's little that you can do to protect against that. But if they're mistake is only exploitable if you are running a web server on the VPS, then perhaps the VM will help.


This falls under the Testing Scope and all parties in a penetration test should anticipate the discovery of protected data and private credentials in the course of the test.

YOUR defined expectation as the client should be the explicit and reasonable assurance that any garnered data and social media credentials will be used within the confines of the scope and remain private and in the custody of the penetration testers for the duration and a stated period of time after the test completion and solely for the purpose of documenting the results.

If YOUR particular environment allows an employees access to corporate materials via their personal social media credentials, THEN YES you should include that within the scope of the engagement. The pentesters shouldn't do anything illegal against the social media provider themselves and hopefully they already know that !

An explicit clause of effective destruction of your garnered data, private credentials and all any "trophies" and any other of your internal materials you advance them or they capture will be destroyed no later than an agreed upon date and with a well known and industry accepted data wiping method of your approval.

There is no contractual agreement that insulates your pen tester from illegal activity, if they behave foolishly, illegally with those captured social media credentials, they'll be subject to applicable legal consequences both civil and criminal. The client (YOU) will have no say in their prosecution.... if something like that ever occurred.


Use asymmetric encryption once to exchange symmetric key

What you propose is actually similar to normal https with session reuse, i.e.

The initial handshake needs asymmetric encryption to identify the server and (depending on the cipher) to securely create the key for symmetric encryption. The transport encryption then is done with symmetric encryption only.
Following handshakes just reuse the existing session and only symmetric encryption is needed.

Thus what you propose exists, is established and I recommend to use it.

  Do you see any downside and security issues in this?

I do not see any obvious security issues in design and implementation because the design is not specific enough and there is no implementation yet. But on the technical side I see several issues:

I don't know how you implement your encryption, but libraries implementing SSL/TLS are already tuned for speed (often use hardware acceleration). Can you easily top this with your implementation?
The SSL/TLS protocol is widely used and heavily analyzed. How about your design?
I've never understood why anybody interested in performance uses text based formats like JSON or XML anyway. If you need performance and low overhead use binary formats like protobuf or the old but established ASN.1 encoding.


Netcat does not receive an response over tor

As you can see the connection gets properly open and closed (thats why your nc quits) but there is no data transferred. This is because torify does not expect you to just pipe data into it I suppose.
To check maybe try using netcat without torify (nc -v -X5 -x localhost:9050 <server> <port>) or get rid of echo and your pipe and try using nc interactively.


Is selecting trusted computer in 2-step verification less secure?

Yes, making a device trusted is absolutely less secure -- but in general it is secure enough. The thing to consider is how easily someone could gain access to the trusted computer in question. Among the questions you'll want to ask yourself before making a computer a trusted device:

Do you control the physical unit? (For example, is it in a locked home or in a key-card-isolated area of an office building?)
Is the computer password-protected? (Do you habitually lock the screen when you step away, or have it set to lock automatically with a short time-out?)
Are you satisfied that the unit is safe from intrusion through the network? (Do you have a firewall in place and do you keep the operating system and installed programs up-to-date with security patches?)


Is tails os susceptible to a cold boot attack?

Could malware interfere with the wiping process?
If there is malware present on the system, then yes, it will be able to interfere with the memory wiping process. If a malicious process spawns many copies of itself in memory, it can prevent the processes which initiate memory wiping from executing, essentially causing the computer to hang. This is an extremely simple attack called a fork bomb, which fills up the system process table and prevents new processes from forming. Even unplugging the USB stick will not kick the computer out of this frozen state, and only holding down the power button can power it off. The malware does not need root privileges either. It can do this as a regular user. This is not a very likely threat though, because it would have to be tightly coordinated with a physical raid against you, which is unlikely. It would be much easier to prevent you from pulling out the USB stick than it would be to get malware on the system. This is not an intrinsic limitation in Linux, however, and Tails could be configured in the future to resist such denial of service attacks from non-root users quite well by using PAM. Malware which has root permissions will still be able to do practically whatever it wants, though.
Is there any way to recover wiped memory?
In theory, yes, but not because the memory can be recovered after it is wiped. On some systems, the wiping fails. This is usually not a big deal because it only saves you a few extra seconds of time. On very old computers, it can save a minute at most. If the wiping fails and your computer has DDR3 or DDR4 memory, just make sure it stays off for 5 seconds or so and the memory will fade naturally. If you have older DDR2 memory, wait a few minutes just to be sure.
If you are asking whether or not a cold boot attack after a successful erasure of memory can recover previous contents, then I would say absolutely not. Not with 21st century technology, at least.
Cold boot attacks against VRAM
There is however a different problem regarding recovering memory, and that is video memory, or VRAM. VRAM in most video cards is usually either true DDR3, or GDDR4/GDDR5. GDDR4 and GDDR5 are based on DDR3, but optimized for higher bandwidth and thus graphical tasks. Because they are based on DDR3, similar cold boot techniques against them likely apply. Tails currently cannot wipe video memory on shutdown. Cold boot attacks against video memory are possible, and they allow for reconstructing framebuffers from while the system was powered on, along with calculations the GPU was making at the time. If your system uses integrated graphics (i.e. the GPU is contained entirely in the CPU, and not a discrete graphics card), then cold boot attacks against video memory on Tails become much harder. This is mostly problematic for people with discrete GPUs. There are a few possible solutions to this, other than simply waiting the few seconds for the memory to naturally fade, but Tails has not yet implemented it. I'm actually working on a few of them in my free time and may contribute them to Tails. Other people are as well, so this is not unknown and it won't necessarily be an issue forever.
But what is the actual risk?
Honestly, I would not worry about the possibility of memory wiping failing or being defeated on Tails. Modern RAM (DDR3 and DDR4) needs to be cooled down to more than -30 degrees Celsius in order to retain any information for more than a couple of seconds. The Tails memory wiping feature is there primarily for older computers using DDR2 (or god forbid, ancient DDR) memory, where if you power off the machine and walk away, someone can walk up to it 3 minutes later and recover a significant portion of the information on it (even that is a worst case scenario. Most DDR2 memory fades in under a minute). With modern memory, they would have to be right there, freezer spray in hand, with the computer ripped open and equipment next to them, as you shut the system down for them to have any chance at recovering memory. And that would be even if you didn't wipe RAM!
As long as you have DDR3 or DDR4 memory, and you are able to shut down your system several seconds before "they" get their hands on it, then you are completely safe. Cold boot attacks are a risk if either you have 1) DDR2 or DDR memory, or 2) your computer is taken from you while it is still on, and your adversary has ample time to prepare and freeze the memory sticks while the system is still running.
All technical details aside, how should you defend yourself?
If an adversary is about to gain physical access to your computer, you must power it off, there is no way around that. If they take the computer and you are not able to get it to shut down, they will be able to do whatever they want with it. But if you manage to yank the USB stick out before that happens, then you are completely safe (from the threat of cold boot attacks).


Transferring passwords to outside counsel

As a matter of policy, I wouldn't use any form of communication that's by default recorded because you never have control over what happens to it and who might have access to it in the future.  That rules out email.  As you mentioned, the public key methods are out too, since the lawyer isn't technically savy enough.

Data normally is unlikely to be stolen in transit, but far more likely to be stolen at rest.  So while email, and a voice call are both unencrypyed, the voice call is far more secure since they normally aren't recorded.  Though these days it's possible that even a voice call to a lawyer might be recorded.

You'll have to set your own level of paranoia, but it sound like you're not the NSA, so I'd say if you and the lawyer both know each other and can recognize each others voice, that's going to be "secure enough" to thwart evil doers.  You'd still be vulnerable to government snooping of course.  Check with your lawyer if exchanging a password is protected by attorney/client privilege.


Is it legal to create a remote administration tool?

If you want to be certain about the legality of something, consult a lawyer.

That said, a "remote administration tool" as in a tool to permit system administrators to remotely manage computers under their control is legal in every jurisdiction I'm aware of.  On the other hand, a "remote administration tool" as in malware planted on somebody's computer to spy on them or take over their computer may fall afoul of various hacking, wiretapping, or other laws.  So the first thing to do is ask yourself which sort you're making.


There is not currently a script to check for this. It would be a trivial change to the existing smbv2-enabled script. Currently, the script has three possible outputs:

No output: SMB of any version failed.
"Server supports SMBv2 protocol": Server supports at least SMBv2, possibly also SMBv1.
"Server doesn't support SMBv2 protocol": Server supports SMBv1 but not SMBv2.

As you can see, there's some ambiguity about whether a SMBv2-enabled host would also support SMBv1. But modifying the script to test each dialect in turn would be pretty simple.

EDIT: This is coming to Nmap soon. https://github.com/nmap/nmap/pull/943

EDIT 2: This is now supported in Nmap 7.60 by the smb-protocols script.


Is a Pattern Lock any more secure then a typical text password?

Password is better, to foreseeable future.

Password is now better, because

The Pattern Lock can be good for convenience, and it may be sufficient to thwart attackers who have not seen you draw it. However, the number of combinations is significantly smaller for Pattern Lock than in typical password. Even if you restrict password to use only characters and use 4 letter password, there is over 400000 valid combinations. However, according to this earlier question Combination of smartphone pattern password, the number of combinations of pattern lock is smaller. On the other hand, pattern has more combinations than 4-5 digit pin.

If you use relatively long password and follow good password selection practices it is certainly stronger.

Note: Password/PIN is easier to use as secret for key derivation functions. For this reason, on some systems, like Android, if you intend to use "Encrypt phone/tablet", you MUST use either password or PIN; not pattern. (Therefore, if you care for the security of your data on the device, you often end-up to use high or mediocre entropy password).

Future pattern locks

The current pattern locks are inferior to password, but is this inherently so?
Amount of choice favors passwords. In password there is anyway tens of characters you can choose in each screen. In pattern, you make choice out of quite few possibilities (different directions). Even if you make grid larger, it is hard to make pattern as efficient as password.

One of important benefits of password is that they are representable in fairly universal format, and therefore, they are solution that can be applied in many places, like computer login, smartphone, tablet, web site etc. Especially for remote usable services (like WLAN password, network password, web site password), pattern lock would be inconvenient as pattern lock is largely tied with the input device.


Is login limiting still needed if we employ multi-factor authentication?

If login rate-limiting is implemented properly, then there are no downsides, and it should be used with or without 2FA (and in fact with the 2FA attempts themselves).  And account lockout is not the proper way to rate-limit login attempts.

Rate-limiting means you restrict the number of attempts a given source can make. Typically this means a given IP address, though you can define "source" however makes sense in your situation.

There are really three types of attacks you're trying to defend against here:
(a) The attacker knows the password -- in which case lockouts won't help even
a little.
(b) The password is easily guessed, like "123456" or "passw0rd", or "zxcvbn". Again, account lockouts won't be helpful because these attackers don't try more than 5 or 10 passwords at the most before moving to the next account. Often they'll try only one. You need to block the attacker, not the account.
(c) The attacker is making a determined go at a single high-value account and will try the whole dictionary and then some. The password may not be easy to guess, but the attacker has all month.

There's not much we can do about condition (a) above, though 2FA can help. Condition (b) is extremely common while (c) is a bit more rare because the success rate is so low. But importantly, both can be thwarted by slowing down the attacker.

Ideally this doesn't mean a hard limit of 15, and then you wait 10 minutes. Ideally you do an exponential back-off. This means after 2 attempts, you wait several seconds. After the third, you wait a bit longer. And then longer after the fourth, and so forth. The limit is enforced in the back-end, and in the front-end you use some client-side logic like a timer in javascript to keep the user from submitting attempts during the waiting period.

I've explained this technique here several times, so I won't go too deep into the details. But the important thing is that it is simple to build, doesn't noticeably inconvenience legitimate users, but it does work very well against determined attackers. By slowing them down, you're effectively setting a hard limit on how many attempts they can make in any given timespan, but doling out that limit incrementally between attempts. And better still, you can detect which users continue to send attempts during the waiting period, which flags them as using specialized software to circumvent your client-side rate-limiting. Cool!

If you set things up like this, then there's no reason to disable rate-limiting. It has no real drawbacks, is largely invisible to users, and offers a reasonable front-line of defense against brute-force attackers.

This only leaves the scenario of a distributed attack against a single login from a large botnet. This is rare enough to never actually happen for most sites, but it's simple enough to detect and address, so I'll leave that as an exercise to the reader.


When using tunneling via meterpreter routes in Metasploit your lhost will become your first target.

So in this case your LHOST should be set to: 192.168.47.144

Try that.


A Proxy that encrypts your data is the same thing as a VPN?

A Virtual Private Network VPN works at the network layer, and you could use it to route any network traffic, while a proxy could be many things. E.g. a SOCKS proxy proxies TCP connections and an SSH tunnel could be used for similar purposes than a VPN, but you are more likely referring to a HTTP proxy, that forward HTTP request. Nevertheless, proxy with an encryption doesn't equal a VPN, and technically they are two very different things.


Identify if files are being transferred from my computer over the internet

Broadly speaking, you could install a local transparent proxy to gain more insight into network activity. This can be done with free software, like Squid, and there are commercial products that do similar things.

You could also use a DNS provider that does logging and filtering, like OpenDNS. This will let you see what connections your computer is making.

Both the proxy and DNS methods above will not catch all malicious network activity, and are quite complex and time consuming to setup.

If your goal is to guarantee that your computer is infection free, then you should backup your files and rebuild from know good media. That means to format the hard drive(s), and reinstall the operating system from a recovery CD (or similar).

It will be faster, safer, and more reliable to rebuild than to try and "keep watch" on a maybe-infected machine.


Using VPN over TCP 80, 443 and UDP 53,2049?

Like the others say, the port won't give any additional security.  The only advantage would be that you manage to "connect through" an egress filtering firewall.

For example, if you connect on port 53/udp, a company will see a large number of (malformed) packets on "DNS", so that may cause a red flag.  A network may also only allow only the use of their local DNS servers (which forward and cache DNS traffic).

Your "best bet" may be 443/tcp, since many networks may just allow this encrypted, binary, traffic.  Having said that, proper "deep packet" inspection would see that you don't have a proper TLS connection setup; and flag this as malicious and throttle it / shut it down.


Find out the least insecure mutual cipher algorithm

Yes, aes256-ctr is the right cipher to choose from those available to you.

Since it's not an AEAD, you need to choose a MAC. You should choose an '-etm' one if you can, and among those I'd choose the fastest.

Also make sure you have a strong key exchange (in descending order of preference: curve25519, ecdh-sha2-nistp256, diffie-hellman-group18/16/14, not something with sha1) and strong host key (in descending order of preference: ed25519, ecdsa with nistp256, RSA, nothing with sha1 or DSS).

If IntelliJ doesn't support a secure ssh configuration, complain to JetBrains.


How is Fingerprint Authentication Secure?

Biometric is not very secure for authentication, but it can be secure enough for identity verification for many applications when there is a trusted witness when the biometric is taken. Biometric is also useful to detect duplicates. For biometric payment, the trusted witness is essentially the merchant. For identity verification, the trusted witness is usually a government employee. Note that four identity verification, the main problem is detecting duplicates and recording biometric effectively prevents the same person being issued multiple identity cards.

Using fingerprint for payment is a calculated business risk vs convenience trade-off. I don't know about the details of the fingerprint banking you're referring to, but I'd guess that merchants that accepts biometric authentication bears the responsibility of ensuring that their customers don't do weird things (like using false fingers) on the payment machine. If the customer or bank claims that a transaction is unauthorized, the merchant would be considered responsible for unauthorized transaction that is issued using their machine and/or merchant account. Many legitimate merchants considers the risk of abusive reversal to be fairly low when considering the transaction limit and additional business they receive due to offering the option. Merchants that facilitates fraud, either intentionally or by negligence, will have to refund any payment, and will be investigated by the bank's fraud team if they detect abnormal pattern of reversals and may become blacklisted.

Risk and security wise, this is not very different than a hand drawn signature, where merchant is supposed to compare the signature visually with the signature on the back of the card. Fraudulent merchant can use a modified machine to record the card number and signature during transaction.

Smartchips used in bank cards and identity cards are essentially very small, low power computer with a secure computation and a storage area that cannot be read out of the card without destroying the chip. The secure storage contains a private key and a card program running in the chip uses public key cryptography to generate a cryptographic signature of the transactions. The cryptographic signature is a very large number regarding a data that cannot be calculated without the knowledge of the private key and would become invalid if any part of the data is changed. In a chip-only transaction (e.g. PayWave, PayPass), the card signs low value transactions without the user needing to authenticate with the card, in a chip-and-pin transaction, the user must input a pin number matching the pin stored in the card before the card signs the transaction.

Because of the much improved security due to the use of cryptographic signature, transactions involving cryptographic chip usually don't put the liability of unauthorized transaction on the merchant. Instead, it becomes the issuer's and customer's responsibility to keep their card safe.

Chip-and-fingerprint can be implemented as a more convenient alternative to chip-and-pin, while being much more secure than chip-less swipe-and-drawn-signature transaction.

In conclusion, yes, fingerprint is not very secure. But when the more secure alternative like chip-and-pin is considered too inconvenient by the target market which readily switch to cash, it is still a security improvement compared to staying with swipe-and-drawn-signature. Note that banks and merchants don't care about the security of your card, if they can offset having to take the burden of the fraud liability with increased transaction volume and faster payment processing.


Are there remote exploits that are easier to perpetrate than installing a keylogger on a standard win10 laptop?

Keyloggers and the like are not "exploits", but are merely malicious programs that may execute as the payload of an exploit or after tricking the user into running them.
But you seem to have identified the problem; if there is malware on the computer, it could read the text file containing passwords. If the password file is encrypted, it could likely just steal the password with a keylogger, or grab the unencrypted database out of memory. Everything on a compromised computer should also be considered compromised.
It depends on a lot of things, but the most likely vector for a home user is probably downloading and executing untrusted programs, which could access all of your user data, or even take over the entire system if granted administrative privileges.


You are absolutely correct, when there is no valid HTTP inside of the SSL encryption, a decrypted flow will not work through a SSL intercept proxy.

One of the things you need to do before implementing SSL intercept is that you need to identify SSL based applications that are not http-based to prevent denied access (handling through Whitelist).

I can only speak about SSL intercept on (forward) proxies.


No, because the msfvenom encoder can only encode shellcode. Encoding an PE would be different because it requires a stub (decrypter) and loader. A crypter or packer is what you're looking for.

For a more detailed description of how crypters work: https://www.exploit-db.com/docs/18849.pdf


You are trying to use a MAC. Applying a hash function on the concatenation of the password and some other data is a custom MAC, and not a very good one with usual hash functions like SHA-512 because of the length extension attack. That's why HMAC was invented.

Using HMAC with a shared secret is a good authentication method. However, due to the inherent insecurity of emails, you would probably want some encryption, too, and for that you should just use OpenPGP (with its OpenSource implementation). Using a software system which already exist is both safer and easier than reimplementing your own system.

Regardless of the authentication method you use, you should add an anti-replay attack: an attacker could send a valid email (which he observed in transit) a second time, thus triggering the email effect again. Replay attacks laugh at MAC and encryption. To defeat them, the server must "remember" past emails and discard exact duplicates.


Is it possible to setup 1-way TLS client authentication without server certificates?

"Client" and "server" can be vague terms if multiple layers (TCP, TLS) are involved. It is possible and even the most common case that only a single certificate is used inside the TLS handshake, i.e. one party is properly authenticated in order to detect man in the middle attacks. This party is commonly the TCP server but it might also be the TCP client.

If a TCP connection is created from a TCP client (calling connect) to a TCP server (calling accept) then it is possible that the TLS handshake is initiated by the TCP server, thus essentially making the  TCP server the TLS client (calling SSL_connect) and the TCP client the TLS server (calling SSL_accept). This way the certificate is provided by the TCP client (which is the TLS server).


Should other processes be running while an iPhone or Android is generating a cryptographically random number?

To get randomness, you must obtain sufficient initial entropy from some "really random" events, that come from physical systems. Once you have sufficient initial entropy, you can extend it indefinitely with a cryptographically secure PRNG. The PRNG being a deterministic process, its output is not impacted by whatever other process may run at the same time on the machine.

The OS kernel is in ideal position to collect that initial seed, since it has direct access to the hardware. A good OS will collect hardware events to feed its internal pool, and run the PRNG, and provide an API to get the PRNG output. On iOS, this is the SecRandomCopyBytes() function, that itself reads the /dev/random special file (in iOS, like in OS X and FreeBSD, /dev/random is identical to /dev/urandom). By using it you are already doing fine; it already has all the cryptographic security that you can reasonably hope for; its security won't be impacted by running animations since the initial seed is gathered quite early in the booting process. On Android, use java.security.SecureRandom -- same discussion (it uses Linux's /dev/urandom).

In much older days, some people were talking about Java applets, that, by definition, were sandboxed and could not access the OS to obtain good randomness. These applets thus needed to find random events from other sources, and about the only one that remained was measuring the speed at which the OS scheduler could switch between two threads (e.g. see this code). That thread-spinning method required an otherwise mostly idle machine; otherwise, the produced numbers were severely non-random. Other methods leveraged the user: they asked the user to wiggle the mouse, and the applet would use the successive pointer positions as source of entropy.

Fortunately, these atrocious gimmicks are things of the past (or so we hope... because sometimes, some developers for banking systems get "creative"). For an app on a smartphone, you have access to the OS facilities, so use them and be happy.


Why can we still crack snapchat photos in 12 lines of Ruby?

This is a serious problem in password-management. The first problem here is the way they managed his key in their source code. SnapChat states that they send the photos encrypted over internet, and it is true after all, but they are using a "pre-shared" key to encrypt this data (badly using also AES in ECB mode) so, every user around the planet has the key to decipher each photo.

The problem here is, how did internet get the key? Piece of cake, they just included it in every app, and somebody just searched for it.

  What is this magic encryption key used by any and all Snapchat app?

  M02cnQ51Ji97vwT4

  You can find this (in the Android app) in a constant string located
  in com.snapchat.android.util.AESEncrypt; no digging required, it is
  quite literally sitting around waiting to be found by anyone.

  On a more positive note (perhaps), in the 3.0.4 (18/08/2013) build
  of the Android app, there is - oddly enough - a second key!

  1234567891123456

It is a very bad practice to hardcode a password in your source (no matter if it is in your headers or in your binaries), the main problem being anyone could find it with a simple "strings" command into your binary (or by looking in someplace you used to share your code with your friends):

strings binaryFile

Then the malicious user can have a look to each string and check if that is the password he is looking for. So, if your really need to hardcode a password in your code you better hide it, but this will just be "security through obscurity" and the malicious user will end up finding the key (so you better think in a different approach).

What can they do to improve their security? Well they could have generated a key for each photo, or they can pre-share a key between the clients that are going to share a picture, public/private keys; there are plenty of options.


Possible to use CAPICOM to extract current SSL certificate?

I have seen reference to adding certificates through CAPICOM usage.  I haven't seen validating or checking one that is in use.  I wouldn't want to use CAPICOM based on the fact that it's a 32-bit only solution according to the MSDN.  Just my perspective, but I have a hard time wanting to dig any deeper when you are warned off of the API by the software manufacturer.

The other point that could make this difficult is that you are looking for the certificate in use, not a certificate in the store.

I did see that you don't want to depend on a particular product.  Does this mean you don't want to use some browser specific function to try and grab the certificate? I would try browser specific functions first.


How does disk encryption mounting work with large disk and low RAM?

In block ciphers (e.g. AES), the data is split into small blocks, and each block of data is processed in sequence. This allows a huge amount of data to be encrypted or decrypted without consuming much RAM.

Load one block of plaintext into memory.
Encrypt it.
Save it.
Move to the next block and start again.

And to decrypt:

Load one block of ciphertext into memory.
Decrypt it.
Use / save it.
Move to the next block and start again.

In this scheme, it is easy to encrypt or decrypt blocks at random. Unfortunately, this is insecure.

Block ciphers run in a particular mode of operation. The simplest mode (the one I just described) is called ECB, or Electronic Code Book. Each block is processed completely independantly, allowing for each block to be decrypted independantly, as we saw above. Unfortunately, this leads to some serious problems with security, where patterns in the plaintext show up in the ciphertext.

The first image is plaintext, the second is encrypted with a block cipher in ECB mode:

Other modes solve this problem by chaining blocks together using certain operations. This causes the patterns to be dispersed:

Most modes of operation (e.g. Cipher-Block Chaining) will require the previous block to remain in memory. However, since a normal block size is only 32 bytes (256 bits) it doesn't require much memory at all to keep it. However, it does mean that every block up until the required block has to be processed first. This is obviously not practical for disk encryption, because to read disk sector 100,001, we'd have to read and decrypt all 100,000 previous blocks.

TrueCrypt uses XTS, a special mode of operation designed specifically for storage devices. This allows blocks (or short sequences of them) to be decrypted entirely separately, without losing the security that non-ECB modes such as CBC provide. This means that you can easily decrypt files on the disk without having to decrypt everything else, whilst avoiding the security problems that ECB has.


Does improving password complexity improve the security of wireless networks?

A strong passphrase is better than a weak one.

On a WPA2-protected network with a simple passphrase, a naive attacker would be deterred - but a sophisticated attacker would not (because they could simply capture the handshake and crack the passphrase).

On a WPA2-protected network with a complex passphrase, even a sophisticated attacker would be deterred (for that particular attack path, anyway) - because they wouldn't be able to crack the passphrase.


SSL: MITM possible if private key is known?

There are two relevant attacks:

An active attacker impersonates the server. You can't do anything about that if you trust the attackers key. So you need to keep the server's private key private, and you have to make sure that you only trust the right keypair. Typically we use Certificate Authorities to attempt to solve the later problem.
A passive attacker sniffs your connection with the legitimate server. If they know the server's private key they might be able to decrypt the SSL encrypted session. This depends on the handshake and thus on the chosen ciphersuite.

With the weak RSA ciphersuites the server's private key has two uses: Authenticating the server and ensuring confidentiality. When an attacker learns the server's private key these connections can be decrypted without impersonating the server.

Stronger suites use ephemeral Diffie-Hellman keys. Here the RSA key only serves to authenticate the server. Confidentiality comes from the Diffie-Hellman key-exchange with keys that are only valid for this single connection. In this case knowledge of the RSA key doesn't allow decryption of the connection. Ephemeral Diffie-Hellman provides perfect forward secrecy because when the private key leaks, past connections can't be decrypted.


How do we verify identity before creating a new admin account?

This can be a particularly tricky problems. You're approach should match the size of your business (will your solution scale), and the sensitivity of the information.

If you look at a company like Trello, they won't change Administrators for you. If I had to guess their reason for this, it is because the risk of them exposing your data doesn't justify losing your business. Most likely, this happens to smaller companies (who don't designate multiple admins), and thus, their loss of revenue is either nothing (the customer is on the free tier) or the $3.75/month/user. It is better to lose one customer because the customer didn't have exit procedures in place than to lose many customers because a data breach occurred.

For other businesses, where larger amounts of money are involved, it may be worth the extra effort of working with the company to change the Administrator.

Put in technical barriers to prevent this from happening

The best solution is to keep this from happening in the first place. Here are some ideas you could implement:

Require two administrators at signup. You can restrict the backup administrator to have only the access to assign a new administrator. Further, you can assign a multi day delay to the assignment right, so that if the original administrator is still in play, they can veto an invalid assignment.
Require the administrator to establish a backup administrator, triggered by a dead man's switch. If the primary administrator doesn't log in after so many days, the backup administrator is promoted.
Establish a random one time use password to be delivered and retained by the company's legal counsel.

If the technical barriers aren't in place, how should you proceed?

You should encourage the company to resolve this issue by contacting the original admin, and having the admin designate a new administrator.
If the original account email was apart of a company domain, the company should use the Forgot Password feature, log into the original administrator email, and reset the password. They may have to reenable the mailbox to do this.

Last resort tactics

First things first, make sure your customers are aware of your Administrative change policy. Give them the ability to opt out or to possibly modify the terms. This should get you some additional coverage if this process is abused to expose sensitive data.

These ideas are going to require human intervention and review, it may be better to charge a fee for this process than to automate it. You want to be as diligent as possible.

Ensure no one is responding to the original email address, and that the relevant user hasn't logged in recently. This should be your first step.
Have them mail you a notarized letter on company letterhead. Obviously the letterhead can be forged, but the idea here is you want to hold some real person accountable (You have to show ID to the notary), should this process be abused. This letter should contain a random token that was emailed to the person who is sending the letter. The email should belong to the customer domain.
Account Fees. If you are authorized to make deposits against a banking account, you may be able to make three random transactions (typically, all less than a dollar), the result of the transactions should be a net balance of 0, but if the user can identify the transaction amounts, you know they have access to the banking information.
Notify other members of the company. You may want to send emails to all or a portion of the remaining users on the account that this process is taking place. If you have a phone number from the billing details, call the number. The idea is to give the company a heads up that this will take place should something nefarious be going on. Give them a phone number or email address to contact if they suspect something is wrong.


Look over my Web API Authentication Scheme

First things first: you are not using the correct terminology. This may be problematic if you are looking for documentation.

What you call "authorization" is what the rest of the world calls "authentication". What you call "authentication" is what the rest of the world calls "session management".

Authentication is about making sure that whoever is at the other end of the line really is who he claims to be. Session management is about extending authentication over several successive requests, which collectively constitute a session. Authorization is about deciding what a specific, duly authenticated user should be allowed to see and do.

When using passwords, authentication is defined as follows: a user U will be deemed "authenticated" if he can demonstrate knowledge of a password that only user U knows. This calls for two important comments:

Use SSL. The "show the password" authentication method implies, really, showing the password. The client should show it only to the proper server (yours), not to a fake server, and certainly not to the world at large. SSL will provide the necessary server authentication (that's what the server's certificate is about) and encryption. Also, SSL will bind the authentication with whatever is afterwards sent over the link, in particular your token. You won't get any decent security without something similar to SSL, and that's hard to implement and run correctly (especially in a Web context), so use SSL.
Don't store passwords themselves. The server does not need to store the password, but only enough to be able to verify a given password. This is where bcrypt is used: you store a password hash on the server. The idea is that if an attacker succeeds in having a look at your database, he won't get all the passwords in one go. That's a second line of defence.

Password hashing has a lot of theory and involves some configurable slowness and salts. The good news is that bcrypt is a good solution, and most bcrypt implementations already manage the salt. That is, when a salt must be generated, the bcrypt implementation generates one internally and properly; and the salt is encoded in the output. This means that the bcrypt output is a string that you just have to store and read back. See this answer for some details. You should not have to muck with salts directly.

For session management, you want to give to the client, after successful authentication, some fast way to tell to the server that it's him again. Sending back a session token is the normal way of ding that.

The token is a secret key: it is a value whose only important characteristic is that the correct user knows it, but not any other. As such, a good token is a random sequence of bits (128 are enough) generated with a cryptographically secure PRNG. You might want to encode that token into characters with, e.g., Base64, so that it better fits text-based protocols and systems (like Javascript); it does not matter.

Other characteristics are merely extra safety tricks:

You may want to restrict the validity of the token in time, so as to force a new authentication regularly or after a given inactivity period. For this, the server must somehow remember the time at which the token was issued or last used.
You may want to restrict the token to a given IP address, on the basis that... what exactly ? If you do things properly, then if the token is stolen, then the attacker has enough control on the victim's machine that he may launch the fake commands from the victim's machine itself. On the other hand, normal users may sometimes switch IP addresses (there are ISP who provide dynamic IP addresses and change them occasionally; a user may have a laptop and use the WiFi from whatever restaurant he currently sits in). In any case, if you want to restrict a given session token to a specific IP address, then the server must somehow remember the said IP address.

In both case, the server must remember. On the server side, whenever a session token is created, the server must be able to map back that token value to the proper user identity. So there should be on the server a table, indexed by session token, which points back to the "session data", in particular the user name. An issuance timestamp is handy here to allow an obsolescence policy, in order to prevent that table from growing indefinitely (entries for old, expired tokens can then be removed automatically).

If you have millions of clients then you may want to offload such storage on the client itself. This is a size optimization. Now (and only now) would you envision a special "token format" which encodes some data that your server would like to remember about the session, but cannot or will not actually store in its database. The generic scheme is the following: for a given session, there is some data D which contains everything that the server wants to remember about the session. This includes the user name, the time of issuance or last use, possibly the client's IP address if you really wish to put restrictions at that level... then the token value is an encoding of D || M (concatenation of D and M) where M is a Message Authentication Code (in practice, HMAC) computed over D with a secret key K that the server stores.

The server uses K to generate the token (i.e. compute M). The server also uses K to validate an incoming token. Such a token can be seen like a sort of ID card: after successful authentication, the server grants to the client a temporary ID card, which can be verified by whoever knows the MAC key, i.e. the server itself, without having to maintain some knowledge of all issued cards. From the point of view of the server, things go the following way: if a client connects and sends a token T, then the server validates the MAC part of T, and if that matches, then server knows that T was issued by itself, and its contents are therefore trustworthy.

This scheme has some consequences:

Since the client does the storage, the server can manage millions of simultaneous sessions without having to pay the storage cost for it.
There is no easy way to enforce an early session close. As long as a client remembers a given token T, and the expiry date (encoded in the D-part of T) is still in the future, then the client can connect back and will be considered authenticated. If you want to be able to force-evict sessions (e.g. as an administrative action) then you will have to maintain some sort of revocation list (a list of seemingly-valid tokens that you decide not to accept nonetheless). Alternatively, by changing the key K on the server, you cancel all existing tokens simultaneously.
The client will see D. If you just want to store the user name, his IP address and his date of last authentication, this is not a problem: the user already knows all that. However, generically, if you want to store user-dependent data in the user token D that the user should not be able to see, then you will have to use encryption (which complements but does not replace the MAC).
You cannot prevent a user from doing a rollback. If a client connects and sends T1 with data D1, and the server sends back a token T2 with data D2, to be used for subsequent requests, the server has no real way to prevent the client from sending back T1 again. This is unavoidable if the server has a "no user-specific memory" stance.
You have a secret key K to manage on the server. Secret keys for HMAC are easy enough to generate (just get 16 bytes from your CSPRNG) but you have to store that key (so that the server does not forget it when it reboots); if the server has several front-ends then all of them must know the same key K; that key K is very valuable to attackers since knowing K allows impersonating every user, so K would have to be well protected (simply storing it in the database would make it an easy prey to basic SQL injection attacks).

Summary: unless you have clear performance issues which require client-side storage of session data, I recommend that you refrain from using a MAC-based kind of scheme. Don't encode user data in the token. Do this:

When a user logs in (the client shows the user name and password, and the password verification with the stored bcrypt value succeeds), generate a new token T as a sequence of 16 bytes (128 bits) obtained from a CSPRNG (/dev/urandom, java.security.SecureRandom, System.Security.RNGCryptoServiceProvider... depending on the OS and language). The server creates a new row in the "session table" which maps T to the user data (name, date of last use, IP address...). T is sent back to the client.
When a user connects and sends a token T, look it up in the session table to recover the user data. It is sufficient that the client knows T to consider the user as duly authenticated.
Prune expired rows from the session table at regular intervals.
And do everything above within SSL.


The way to find out if you have a virus is to use an antivirus.  Basically, in the question you ruled-out the only real workable solution.
A second idea would be to make a reference system that you know is safe. You can compare the real system with the reference system. Use other tools than Rufus & disk imager. If the reference system is different, you still are not sure that the problems are caused by Rufus or Win32 Disk Imager.
If you want to know if one of the two specific programs has given you malware, you must compare them with known-good versions.  You can do that after they have been used, but theoretically, they could have changed themselves when they ran.


Known windows malware propagated via unmounted iPhone

This is a rather broad question with a deceptive title. The short answer: HIGHLY unlikely your iPhone is the cause of your machine becoming infected. I will answer WHY I make this statement. The instances of iPhone based malware are pale in comparison to say Android, irrelevant, but true. To explain this, one need understand that in order to sell ANYTHING via Apple's iStore, a developer needs to pay fees, provide EXTENSIVE identification papers (license, state ID, etc).

Even if you were using say an Android it is STILL unlikely your phone is the medium. Further explanation on this: So a virus/malware author makes an Android based piece of malware. You have an APK, maybe some bad java/javascripts, these affect the infected device. The calls the malware will make, are targeted. So Android based malware would NEVER run on say Windows.

Now before someone states: "You're wrong" let me clarify this... Neither Android, nor iPhone based malware WILL RUN on a Windows machine. However, a dropper will. A dropped will/can go out to the internet and get a specific piece of malware of disaffect the infected machine. For example:

Dropper --> hey what kind of machine am I on? --> save to POST --> POST to C&C
C&C --> oh, alright so you need this version ... here download it

Now let's look at the premise of what you asked: "Can someone on my phone, copy itself to a shared drive... Then execute to infect?" Highly unlikely. Most malware authors tend to target that which they are good at. This means, most authors targeting say iPhones, are going to usually stick with targeting iPhones (cocoa, etc., whatever they're familiar with). Unlikely they'd risk detection by 1) exploiting an iPhone, only to shove in Windows based executables which would trigger all sorts of warnings causing detection quicker.

Pretty long answer so far. Now the initial (root case) of the question is: "How am I getting infected." Without knowing WHAT it was you got infected by (e.g. ZBot, Zues, NIMDA, SDBOT, etc.) anything else answered is kind of moot. You can get infected by many things, visiting a site, XSS, USB keys, and so on.


Tips for a secure iptables config to defend from attacks. (client side!)

I realize there are different opinions, but one major attitude of people who really know about networking and security is that most of these iptables/sysctl rules are redundant, if not damaging to you and the network. Some will aggressively criticize you for breaking with standard behavior without reason. Some examples:

The standard TCP/IP behavior is to REJECT so that the peer gets some hint on what is going on. Maybe someone just typed a URL wrong or your admin is counting the hosts or somebody wants to connect to your gaming server but typed the wrong port. With DROP they only get obscure and annoying timeouts.
There is no need to drop invalid or malformed packets, all of these attacks are a decade old. The Linux kernel devs are much more up to date than you concerning which kind of packets are valid and which not. "What about future flaws", some might argue. Well, how do you know the future flaw will be in the TCP handler and not in the iptables TCP parser?
Most of the sysctl settings are default. If they are not, there is usually a reason. Eg, why disable sending redirects? I find it very useful to be informed by a peer that my routing is bad,  even if I would never react("accept_redirects", default=0) automatically.
With your log_martians and other logging rules I hope you also have a quota on /var/log, or it will be big fun to remotely fill your disk, usually killing your services/apps. In addition, you should use a rate limit for the logging or someone might fill the quota to prevent you from  seeing the SSH password bruteforce attempts in auth.log, or other stuff. Are you actually reading those logs on a desktop? I recommend logcheck.
You appear to block ICMP. Apart from the mentioned DHCP issue, this also prevents PMTU discovery. Without PMTUD, you will get strange behavior when you use the system in places with DSL connection or other network settings. Some packets will just be dropped and nobody tells you why.
Filtering outbound packets is kind of obscure. Do you not trust yourself? You should generally not run any programs you cannot trust. Commodity operating systems are mostly incapable of isolating these programs from eavesdropping or even manipulating other program's data (e.g., cache timing attacks)
You require NEW packets to have SYN. This will break if a TCP connection is continued after the respective state in iptables already timed out. Not sure what the default timeouts are, but some netfilter guy warned about it.

So, when should a desktop have a firewall?

If there is a specific attack in the news that your current OS or servers are vulnerable to, and one of the recommended quick fixes is a firewall rule.
You have to run certain services that do not allow secure configuration. Most do, and the rest is best replaced by secure alternatives.
You have more complex networks with several VMs and/or interfaces on your desktop.

The first and foremost tool for your network security is the system update. Secondly, there is netstat and nmap, which you should use to find and confirm what services you are running. Then just disable those you don't need or confine them to 127.0.0.1.

Bonus if you read this far: Packets are either ESTABLISHED,RELATED or NEW, everything else you drop. You also drop NEW unless only SYN is set. Since ESTABLISHED,RELATED seems to check flags, this makes all of the --tcp-flags rules and also the -f rule redundant. Same for OUTPUT, but since no packets are ACCEPTed for OUTPUT anyhow, that probably doesn't matter.


Allow or Deny Access to a Network Based on Client Hardware

So in terms of gaming companies blocking illegal software, as @lucaskauffman and @terrychia mention in commments this is typically done by the company issuing license keys to each user and then doing an online check during installation/operation that the key is only used in one place and is a valid key.

If you're looking at restricting access to a system based on hardware characteristics or perhaps installed software/configuration that sounds more like a job for Network Access Control (NAC) style systems.

They typically work by deploying an agent to each client which then runs a series of checks returning the result to network hardware that then only allows access to the network if the result is as expected.

A big warning with this kind of system is that a determined attacker will likely be able to bypass it.  The security adage is that once the attacker has control of the hardware (in this case the client) they can usually bypass controls deployed to it.

It's not to say that it's not a good control, but that it's only effective in some situations and against some classes of attacker.