What are security risks of connecting to my home vpn from my work?

I can understand why your IT Manager is upset.

How would you feel if some one, without your consent, bridged an unknown network with your home network?

You arguably bypassed any controls they had in place and bridged a completely foreign network with that of (what I can only assume is) a multi million dollar corporation.

  What are the security risks of doing so, given the fact that the
  servers are in the same network my work's PC is, and how can I
  minimize them if any?

The risks are the same as any other PC/Server exposed to the internet - endless.

  I sincerely don't see many risks,

And that is precisely why your behavior could be construed as reckless. Just because you don't see any risks doesn't mean there are none.

  apart from having a super hacker in my home network which would be
  stupid because who would be interested in it?

There are many reasons for a hacker to be interested in your home network. For example:

Image from: http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/


Teaching a loved one about secure coding practices

I would say a great way to learn is for her to break the applications she has already written.

Assuming she is writing web applications, point her towards the OWASP Top 10. Have her see if she can find any of those flaws in her own code. There is no better way to learn about security concepts than actually seeing it happen on your own code.

Once a flaw has been found, have her rewrite the application to fix the flaw. Doing so will allow her to appreciate the effect of things like sanitation and validation of user inputs and parameterized queries.

Take incremental steps. I wouldn't jump straight into designing a new application with security in mind before truly understanding what type of codes result in security flaws.


What are some good ways to verify user identity for password resets?

Essentially handling this revolves around having some combination of factors that can be used to assure that the user requesting the reset is the same person who has authority to the account.

As you've noted in your question one of the problems tends to come where retrofitting a password reset system to an existing application as the required information may well not have been gathered initially.

Methods I've seen include

e-mail address.  I primarily see this on websites where the user has registered with that address and therefore it's used as the reset location.  If you have that and no other information it may be a tenable solution.
SMS messages.  Mobile phones tend to be unique to a given person in most cases, so reset to phone (either by voice call or SMS) could be a decent option.
Online reset with management approval.  Heavy to setup but I've seen systems where if a password reset request was made e-mails were sent to "approved" persons (eg, manager) and those persons then confirmed the request (handy in big companies to reduce helpdesk costs)
A Bad option (from a security standpoint) that I've seen is confirmation of some personal information that the company may have about the staff member (eg, staff ID, managers name, dept name etc)  This might be reasonable with regard to complete outsiders, but there's a big risk of internal users already knowing thise

Ultimately the checking with managers option is also common and hopefully users could understand that it's not IT staff not trusting them, but that IT staff have to make sure that someone else doesn't access their accounts without authorisation..


I wonder if Location Accuracy has also the purpose of feeding new
  locations of accesspoints to Google.

Yes,When you select the option to pin point you they use a wide variety of things.When it does do they also send data to better those services.Google initially started mapping wifi points using cars.

  This summer it was revealed that Google Street View cars, besides
  taking photos of your neighborhood, were also collecting the street
  addresses, Wi-Fi service set identifier (SSID), and the unique Media
  Access Control (MAC) identification information for computers, Wi-Fi
  access points (AP)s, and routers

As for using your data to better their geo location services is also true.
Here is the official statement of such

  Most mobile phones are equipped with GPS, which uses signals from
  satellites to determine a device’s location – however, with Google
  Location Services, additional information from nearby Wi-Fi, mobile
  networks, and device sensors can be collected to determine your
  device’s location. It does this by periodically collecting location
  data from your device and using it in an anonymous way to improve
  location accuracy.


FastCGI communicates between the webserver and the CGI host using IPC rather than environment variables, so the main attack vector (the webserver setting environment variables for CGI) is gone.  However, it is still possible for you to be attacked if your PHP script itself sets environment variables based on user input before executing bash.


REST API - XSS prevention - When and how?

When do I escape the data?

Basically, as late as possible. The database is somewhere to store data, it is not a place to encode (escape) data. Of course use parameterised prepared statements to prevent any SQL injection attacks, but that should be as far as you take it. Your goal for writing to the database is simply to store the data successfully and to avoid any attacker breaking context and manipulating any queries to their own advantage.

Always think if a client/manager/supplier needs an export of the data, it is much easier if this data is already in plain format. It can become a headache if you then have to start converting it from HTML/JSON and then back into the correct format for export.

So the solution is to encode for JSON (but not HTML) when you deliver the JSON (preferably using a tried and tested Java JSON encoder).

You don't mention how you are rendering in your Android app. If you are using a non web control then you don't need to escape at all. If the controller doesn't interpret HTML and you are simply setting text elements then the application will not run any injected scripts. If you are generating a webview in Android on the client then you should HTML encode at this point.


Is it safe to store a passphrase encrypted SSH key in git?

Read up on Kerberos and develop a strategy to deploy Kerberos at your company.

ssh has Kerberos integration via the GSSAPI (you may need to rebuilt ssh.)

Kerberos will solve your key management problems and its APIs should dove tail into your own APIs.

Why do I suggest going down the Keberos path?

Because many of the activities you are doing sound exactly like problems that Kerberos has already solved (strong passphase, key management, etc.)

Kerberos is the more robust solution that you seek.


Isolation AWS resources with multiple subnets vs multiple VPCs

A VPC is a virtual network within your AWS account, and within that VPC you can have multiple subnets.
There's 2 types of subnets, a public subnet and a private subnet.

A public subnet, is just a subnet that has an internet gateway attached to it -- meaning it has the ability to connect to/from the internet.
A private subnet is a subnet without an internet gateway attached. No internet access -- at least not directly.

If you have just one subnet across your VPC, you'd effectively have one giant public subnet, which means everything has potential internet access, at that point you'd be relying on Security groups only for your network protection.
Multiple VPCs with multiple subnets are generally more difficult to manage (you'd have to peer the VPCs together), and unless you absolutely need them I'd suggest a single VPC with multiple subnet approach.
Within that construct you can limit access to subnets/instances via both NACLs and Security Groups, which generally speaking is sufficient for most use-cases.


How to recognize if this code is dangerous

Print instead of executing

In this case, you have the deobfuscation code right in front of you. While it may be interesting to understand how it works, that's not necessary - it's obvious that the process flow is that it deobfuscates some payload to variable Container1 which then gets executed.

What you can do is replace the execute Container1 with something like (assuming this is VBA) MsgBox Container1 and just run the code. Of course, it's safer to run any potentially malicious code in a sandbox virtual machine and not on a computer that you care about, even if you believe that you know what it does and doesn't do - as anyone can make a mistake in evaluating that.

It's quite plausible that this will just reveal some 'second stage' that will still need further analysis and deobfuscation, but that's a different learning exercise.


Why are some OpenSSH CVE patches not being updated when checking for updates?

Should I be manually installing these patches, or should I just try installing the latest version of openssh?

It depends on what you are trying to achieve.

The important CVEs are in the package already fixed, as you found out. The others might not be, because they are not exploitable in the supported configuration or the effects are not severe. This is why the CVE numbers have their descriptions and impact. If you search around, you will see the explanation why it was or was not backported to RHEL6.

Updating OpenSSH to current version might make sense in some cases, but the interoperability with the rest of the system can be broken, you can get worse user experience or security in some cases. You will also not get any more bugfix and security updates from Red Hat. In this case you would need to follow the upstream releases, update manually and possibly add the patches that are used in Red Hat OpenSSH package to get similar user experience and security.


Why is there no referer when pointing to a secure page?

Actually the HTTP referer is not a mandatory header. The client can decide to leave it blank, or to send false information. I noticed Google Chrome does not always send the referer, and when it comes to HTTP -> HTTPS links, nothing is send for the first few requests. My best guess would be to say that the browser makes sure all the requests have at least been requested once over HTTPS, before the referer are added. Other options from this post:

It will/may be empty when the end user:

entered the site URL in browser address bar itself.
visited the site by a browser-maintained bookmark.
visited the site as first page in the window/tab.
switched from a https URL to a http URL.
switched from a https URL to a different https URL. (Some browsers)
has security software installed (antivirus/firewall/etc) which strips the referrer from all requests.
is behind a proxy which strips the referrer from all requests.
visited the site programmatically (like, curl) without setting the referrer header (searchbots!).

Update on comment

Yes I would expect it to change. For a browser it doesn't matter who triggered the location, you, a script, or a plugin, but then again, read the above.


Odd PHP error referring to Fallaga Priv8 404 Shell when visiting a web site

This is indeed the code for a reverse shell. The server is most likely compromised.

Web shells are not intended to harm visitors, so neither your browser nor your OS were hacked. Moreover, it seems that it didn't even load correctly.

If you have an account on the site, then do not login until the company tells you they fixed it, since the attacker could grab your credentials.

If you used the same password elsewhere, you should change it on the other sites right now.


Is there a limit on the layers of encryption a file can have?

Theoretically, there's no limit on the number of times you can encrypt a file. The output of an encryption process is again a file, which you can again pass it on to a different algorithm and get an output.

The thing is, at decryption side, it will have to be decrypted in LIFO (last in, first out) style, with the proper passwords.

For example, if your file was first encrypted with algo1 with password abcde, and then it was encrypted with algo2 with password vwxyz, then it will have to be decrypted first with algo2 (with password vwxyz), and then with algo1 (with password abcde).

This method makes sense if you're sending the keys through different media or channels. This method would be of little use if all the passwords are sent through the same channel.


How to securely store application data on mobile device

You would do it the same way you'd do it on a computer, but once the machine is compromised, all bets are off, and you're mostly wasting your time. You may check out this related question on which my answer suggests deriving a key from the hardware and using it to encrypt the sensitive data but even then, that only buys you more time until the attacker reverse-engineers how your app generates this key and generates the same one using his malware running on the same phone (thus having access to the same hardware).

An HSM may help in this case but if your app can get the data off the HSM, so can the attacker with root access to the machine. HSMs are only effective against data that isn't supposed to get off of them, like private keys (they're generated on the HSM, the HSM itself uses them to do crypto operations on data sent by the host machine but it never reveals the actual keys), but that isn't applicable in your case since you want to protect a message history which the user would want to read (ie, get back from the HSM).


is there some good reason from a security perspective to allow only TLS 1.0, or is it simply pure "laziness"

It is in most cases just the TLS stack used. One of the most common stacks in web servers on UNIX/Linux is OpenSSL and the still widely used (and supported) versions 0.9.8 and 1.0.0 can do only TLS 1.0 and lower. TLS 1.1 and TLS 1.2 were only added with version 1.0.1 (04/2012). On the Windows side SecureChannel supports TLS 1.1 and TLS 1.2 since Windows 7 and Windows Server 2008 R2 (end of 2009).

And while changing the TLS stack might be doable for some sites it involves is most cases either the upgrade of the operating system or at least to run some parts of the system in a configuration not supported by the vendor.

  and there is no good reason not to allow TLS1.1 and TLS1.2 in addition to TLS1.0?

If the server has support for TLS 1.2 there is no  real reason to set the server up for only TLS 1.0. In fact, TLS 1.2 not only gives better security but also new cipher suites which can lessen the load on the server.


How to crack AES-based Kerberos TGS tickets (Kerberoasting)?

https://github.com/hashcat/hashcat/pull/1955
Looks like Support has been added, but may not be reflected in the release yet.

https://twitter.com/hashcat/status/1105909927825104896


If not using HTTPS/SSL/TLS is such a security risk, why don't sites/browsers force HTTPS for all sites that have it?

Because that's not easily automatable

  If there is such a risk of bad things happening, why is HTTPS not forced?

Because that can easily break the site. And then users will just abandon that browser and pick another one that does not break their sites.

I run the "HTTPS Everywhere" plugin in my browsers. And they try to do something similar. But even they have to use a massive 22k-file ruleset. (From what I understand the rules are partially generated and partially hand-tuned.)

And judging by these comments in the Amazon-Ruleset, it's not that easy to write working rules that stay working:

  <!--    Amazon has a history of breaking us soon after
        adding rulesets, so these are here to detect that.

(Test-URLs omitted)


What is the example parameter in the OAuth 2.0 RFC

It is there to show that if you're writing a client, you may meet an implementation that returns additional parameters that are not mentioned in the RFC, as explained in section 8.2.

(For example, this implies that you should not use a JSON parsing framework that errors out when it meets unknown parameters).


When should TouchID/Fingerprint log-in expire?

Why not treat it the same way as a password? It is just another factor of authentication.

NIST800-63B recommends re-authentication at 30 minutes for inactivity or 12 hours of active use. https://pages.nist.gov/800-63-3/sp800-63b.html .


Is there any definitive way to tell if an email is a phishing attempt?

There are a number of both technical and non-technical ways that someone can identify a phishing attempt.

Communicate out of Band. The easiest reliable way is to communicate with the proposed sender out-of-band. Call them, send them a what's app if applicable, signal, whatever. If an organization or an individual didn't send you an email they can tell you over the phone. Just remember to use a phone number that is not included in the email.

Proofreading - Much of the spam, even a lot of spear phishing, is very poorly written. Poorly constructed sentences and spelling errors are pretty good indicators of Spam.

Hovering over links - Phishing links will typically be "obfuscated" to look like they link to a login page. For instance the text may be https://login.facebook.com however when you hover over the link you notice it's some long verbose domain name. Tell-tale phishing.
EDIT : As Mehrdad and Bacon Brad have pointed out this method may provide mixed results. Links can be used in a variety of attacks such as CSRF / XSS attacks, and the link provided may also lead to an authorized third party.

Email Headers - Perhaps one of the more tech-savvy way of telling whether or not an email is legitimate is by looking at the E-mail Headers. E-mails contain metadata that states where emails originated from. You can usually tell by looking at the email header if an email originated from an authenticated source with these headers. Note that this is not foolproof as many organizations may outsource mail campaigns, but email coming from a private IP address could indicate a phishing email.

Macros - Does the word doc you've just been sent state you need to enable macros in order to see the document? Don't you go doing that.

Social Engineering - Many phishing email tactics will play off human emotions and employ many well known Social Engineering techniques. Statements like "You must click on this link and re-activate your bank account within 24 hours or your account will be closed" are meant to make the receiver panic. When we panic we make illogical decisions. If you feel an email is playing off your emotions you might be getting phished.

Is this normal behaviour? - Institutions are well versed in the ways of phishing and as such they are not going to ask you to click on embedded links in an email to "reset your password" or "confirm your account". If your spidey sense is tingling, probably phishing.

In my experience there is no one silver bullet in dealing with phishing. During penetration tests spear phishing always works. The above information will help you spot attempts to phish you, but the easiest and most efficient way to confirm or deny a phishing attempt is to call the "sender" to confirm if it's legitimate.


How does this website prevent directing away from it

I did visit the page (from a safe place!) and it's triggering the  beforeunload event to change the URL, like this:

var exit=true;
var temp_url = document.location.href;
var url_pieces = new Array();
url_pieces = temp_url.split("/");
var goto_url = 'http://www.imagesnake.com/ad.html' ;
window.onbeforeunload = function () {
if(exit==true){
    location.replace(goto_url);
    return "   Special Offer: Free Porn Videos ";
}
}

I did this with Chrome, and got the "Page is asking if you want to leave..." dialog, and was able to close the page.  I can guess that, depending on the browser, one might not be able to get out.

There may be other tricks in the plethora of JavaScript the page loads.  This is the one that stood out for me, based on the browser dialog.


According to the Argon2 Specs, specifically section 9 Recommended Parameters, the following procedures should be done to determine which parameters to use:

We recommend the following procedure to select the type and the parameters for practical use of Argon2:

Select the type y. If you do not know the difference between them or you consider side-channel attacks as viable threat, choose Argon2i. Otherwise any choice is fine, including optional types.
Figure out the maximum number h of threads that can be initiated by each call to Argon2.
Figure out the maximum amount m of memory that each call can afford.
Figure out the maximum amount x of time (in seconds) that each call can afford.
Select the salt length. 128 bits is sufficient for all applications, but can be reduced to 64 bits in the case of space constraints.
Select the tag length. 128 bits is sufficient for most applications, including key derivation. If longer keys are needed, select longer tags.
If side-channel attacks is a viable threat, enable the memory wiping option in the library call.
Run the scheme of type y, memory m and h lanes and threads, using different number of passes t. Figure out the maximum t such that the running time does not exceed x. If it exceeds x even for t = 1, reduce m accordingly.
Hash all the passwords with the just determined values m, h, and t.

The "tag" in this case refers to the output of Argon2. So as the document highlights, 128 bits (or 16 bytes), should be enough for most applications. Generating a longer output will not give you more security. You should generate a longer output if your application needs the output to be longer for some other purpose (e.g. generating 256 bits output to use as a key for AES-256).

As for the memory cost compared to the number of iterations, I asked a similar question. The answer to that question, as well as the specs, recommend the maximum amount of memory possible given your environment. This question and its corresponding answers explain why it makes sense to maximize memory usage, as long as you have at least 3 iterations over that memory. In your code, NUMBER_OF_ITERATIONS is set to 4 as a recommended minimum value, which seems safe as a minimum.

As a side note, you should actually benchmark your values. What primarily matters is the amount of time it takes to perform the calculation of one Argon2 tag. The specification added above, as well as the questions I linked to, detail this process well.


Is it possible to catch public key certificate in network and hack the public key so you could pretend that you were someone else?

The public key is contained in the certificate which gets sent from the server to the client inside the TLS handshake, so that the client can check if it speaks to the correct server to prevent man in the middle attacks. The certificate is signed by the issuer CA. This signature also includes the public key.

If the public key gets replaced by an attacker the signature of the certificate will therefore be invalid. In this case certificate validation fails and the TLS handshake will be aborted. This means the attacker not also needs to replace the public key but also needs to recreate the signature of the certificate so that it gets valid again. But, to do this he would need to have the private key of a CA which is trusted by the client, i.e. needs to have either compromised such a CA to get to the private key or needs to have compromised the client to install a new trusted CA.


Cryptographically signing content / download

Yes, code signing with asymmetric crypto is very common. The exact mechanics vary by OS, but the general principal that the author of the software package, or the central repo / app store, or both, signs every code package with their asymmetric key:

Android code signing system
iOS code signing system
Windows code signing system
Linux (ex.: Red Hat) code signing

The tricky part here is that you need some way for the end-user's device to trust your signing key; simply attaching the public key to the binary doesn't work because an attacker could modify your binary, re-sign it with their own key, and replace your public key with theirs.
Typically this is solved by signing with a certificate that chains to a trusted CA or PGP root key, for example either a publicly-trusted CA, or an internal CA or PGP key that is trusted by your whizpop devices.
You could do as you suggest and have client fetch the public key of the signer via an API, in which case trust in the key will be rooted in the TLS certificate that the API server is using. There are lots of options.

TL;DR
Yes, signing binaries with asymmetric crypto is very common. You'll probably need to do some work to establish trust in the signing key. For inspiration and ideas, see the links to how each OS handles code signing.


The suggestions of suitable exploits are generated by banner grabbing in most cases. For example, if a webserver returns something like nginx/1.9.4 in the header Metasploit will assume that this software is running in the specified version. But this is not always the case for various reasons. (Backporting of security patches like Debian does for example)

The Check Exploits option will add deeper checks and in various cases, it will try to exploit the vulnerability since in various cases there is no other way to determine whether a target is vulnerable or not. But it hardly depends on the module which is used and not all modules are supporting the check method.

For most of software testing it's best practice to avoid doing it on production systems. This is especially the case for pentests since in most cases an exploit is triggering undefined behavior of the software and its impossible to predict the outcome. I highly recommend to split the scanning (even this can trigger unwanted effects) and testing into smaller portions and doing it against a test system or at least outside of the main business hours.


Downloaded a file which turned out to be a shortcut that ran the following command, not sure what it did

certutil is a built-in program in Windows used to manage certificates. The above command would be decoding the certificate present in the file and install malware. An article illustrating how this could be used.


Comparing the standard HTML form POST for user authentication vs Javascript/AJAX

There should be no difference in terms of security, since the POST is handled by the browser in the same way as a form. If you're running HTTPS, it'll go over HTTPS too.

However, keep in mind that complex ajax-based apps are statistically more likely to be vulnerable to XSS than flat HTML pages. This doesn't mean you definitely are, it's just something to watch out for.

Things to consider:

Ensure that your script is served via HTTPS. You'd be surprised how many people serve their scripts from a CDN over plaintext HTTP.
Proper cross-domain policy should be specified in crossdomain.xml
Consider enforcing strict transport security.
Configure your Content Security Policy properly.
Avoid eval, escape output using contextual escaping, etc.


Full Disk Encryption and Network security

In case a laptop got stolen, FDE will make sure that:

Private keys cannot be stolen (e.g. from a web server, or indeed from a VPN)
Stored WiFi password cannot be stolen
Other passwords cannot be stolen (from router, switch, etc.)
When device registration is mandatory, an attacker could use the already registered device to access the network.


Are files recoverable that have been deleted BEFORE encryption?

I believe modern android versions support "fast encryption". To quote the documentation -

  fast encryption, which only encrypts used blocks on the data partition to avoid first boot taking a long time. Only ext4 and f2fs filesystems currently support fast encryption.

This to me suggests it will not overwrite currently unused storage. If you are concerned I would suggest filling the disk as completely as feasible (either before encrypting or while encrypted).

It is worth noting recovering deleted files from flash media is considerably more difficult than from spinning disk media. As such the risk here is extremely low.


Confused about kiosk security: am I being overly cautious?

How secure should it be

Given customer input their personal data into the kiosk owned by your company, it is critical that the kiosk be hardened to be as secure as possible.

  What steps can I take to make it more secure?

Do not run the kiosk in Administrator mode unless such elevated privileges are critical to its functionality

The kiosk software currently runs in Administrator mode, which is ill-advised. Normally, systems should be run with the minimum set of privileges needed to perform its function, a concept known in IT security as Least Privilege. In this way, if an attacker were to compromise the machine, it would mitigate somewhat what he / she can do.

Implement a means to segregate the kiosk machine from your internal company network

You mention that the kiosk only needs Internet access. It is advised that you segregate this kiosk through a demilitarized zone (DMZ) and implement ACL rules through a firewall to prevent direct connections to your internal network. Any connections from the public facing Internet is by nature untrusted

Implement means to securely transmit customer data from when it is inputted into the kiosk to the destination where it will be processed.

Given the kiosk is Internet facing, if a secure method of data transmission is not used such as TLS 1.2+, sensitive customer information can be easily sniffed off the wire by attakers on the Internet.

Implement means to authenticate the user who remote logins to the kiosk.

You mention that the kiosk software is owned by a third party. Without a reliable means of authentication, you cannot trust that the individual connecting to is who he / she says they are. There should be means such as RADIUS or TACACS+ that centrally authenticates remote users. Only when their identity has being verified by the system should they be granted access.

Implement means to securely store customers information and mask information entered by the customer on screen.

Given customers enter their personal data into the kiosk, it is important that sensitive data such as SSN be masked when displayed on the screen. You did not describe the physical environment where the kiosk is located, but there could be a significant risk of leakage of customer data through  shoulder - surfing. You would also want to verify that sensitive data is securely stored by the kiosk, ideally in encrypted and or hashed format, depending on whether access to the input data is important. Use a strong encryption or hashing algorithm such as AES with a long key length to maximize protection.


When did development on various TLS versions begin?

Tldr
This is what the little research I did was able to find. Most of these dates are as you can read in the longer version, based on the first submitted draft of the respective protocols and not the first time they've been talked about. I hope this might help in your work anyway, and that it might help when doing further research.

SSLv1 - November/December 1993.
SSLv2 - At the end of year 1994, before November 29.
SSLv3 - 5. December 1995.
TLS1.0 - 26. November May 1996.
TLS1.1 - 19. February 2002.
TLS1.2 - February 2006.
TLS1.3 - 17. April 2014.

This is by no means a complete and "100%" list, and I hope someone wants to take the little research I've done and further expand on it.
The longer, more historical version
AS StackzOfZtuff also noted, the IETF Datatracker is a valuable tool for digging backwards in the history of RFCs, and will be a nice companion for the rest of your digging.
Netscape
SSLv1

Netscape Communications started to develop the SSL protocol soon after the National Center for Supercomputing Applications (NCSA) released Mosaic 1.0 - the first popular Web browser - in 1993. Eight months later, in the middle of 1994, Netscape Communications already completed the design for SSL version 1 (SSL 1.0)
SSL and TLS: Theory and Practice by Rolf Oppliger

Version 1 of Mosaic was released for the Windows platform November 11, 1993. (In the beginning there was NCSA Mosaic....). We could then guess that SSLv1 was done around July 1995.
Version 1 was never released publicly. Rolf Oppliger tells the tale why in SSL and TLS: Theory and Practice:

[SSL v1] circulated only internally (i.e., inside Netscape Communications), since it had several shortcomings and flaws. For example, it didn't provide data integrity protection. In combination with the use of the stream cipher RC4 for data encryption, this allowed an adversary to make predictable changes to the plaintext message. Also, SSL 1.0 did not use sequence numbers, so it was vulnerable to replay attacks. Later on, the designers of SSL 1.0 added sequence numbers and checksums, but still used an overly simple cyclic redundancy check (CRC) instead of a cryptographically strong hash function that is one-way and collision-resistant.

SSLv2 (Also known as SSL 0.2)
Netscape Communications came up with SSL Version 2. (SSL 2.0) at the end of 1994, to resolve the problems mentioned with SSL 1. SSL and TLS: Theory and Practice by Rolf Oppliger
tools.ietf.org/html/draft-hickman-netscape-ssl-00.txt
There is a mirror of the SSL 2.0 draft located in Mozilla's archives, but there is no date when the draft was orignally started or submitted, only when it was revised.
The spec got revised a couple of times:

November 29, 1994
December 22, 1994
January 17, 1995
January 24, 1995
February 9, 1995

Funfact:

Both SSL2 and SSL3 have 16-bit (two-byte) version number fields. SSL2 interprets this as a single 16-bit integer, and the official number is 2, e.g. 0x0002. SSL3 interprets two-byte version numbers as a one byte "major" number and a one byte "minor" (or fractional) number. So the value 0x0002 is interpret by SSL3 as version 0.2, not 2.0. http://www-archive.mozilla.org/projects/security/pki/nss/ssl/

SSLv3
SSLv3 was according to this draft first submitted to IETF 5. December 1995. draft-freier-ssl-version3-00.
IETF
TLS 1.0
The first TLS 1.0 draft was written in November 26, 1996 according to draft-ietf-tls-protocol-00.txt.
[edit 14:22 5/7/2015] As commented by @user23127, development of TLS 1.0 was started in May of 1996. "SSL and TLS: Designing and Building Secure Systems" by Rescorla, Eric, page 49, section 2.6
TLS 1.1
The earliest document I can find for TLS 1.1 is the [draft-ietf-tls-rfc2246-bis-00](https://tools.ietf.org/id/draft-ietf-tls-rfc2246-bis-00.txt
https://datatracker.ietf.org/doc/rfc4346/history/). Uploaded to IETF 19. February 2002 . Note that the header of that documents says:

The TLS Protocol
Version 1.0

They first added version 1.1 to the draft in the second revision published 6. October 2002: draft-ietf-tls-rfc2246-bis-02
TLS 1.2
The draft draft-ietf-tls-rfc4346-bis-00 states February 2006.
TLS 1.3
The earliest draft on IETF is this one: draft-ietf-tls-tls13-00.txt uploaded 17 April 2014. This matches the first commit on the GitHub repo tls13-spec that you linked to.


Antivirus / Wireless PCI v2 Controls Scope

No... but it depends if you're confident with the layer isolating what's in-scope and what's out-of-scope. If so, you're good.

PCI requirements only applies to what's in-scope - nothing else. The tricky part is actually to define this line. It has to be black and white and that's not easy - too many shades of grey.

To be sure, as always validate with a QSA (Qualified Security Assessor).


How to directly connect to devices behind NAT from the internet?

In a simple answer (if I'm understanding this correctly), yes. You can accomplish this by utilizing reverse SSH tunneling.

You'll need to setup the tunnel on "B" first utilizing socks proxying (can be done through Putty), then you'll need to route your traffic through "A" for the requests.

When the responses return, they'll be directed through "A", back to "B"; esentially reaching "B directly with A".

Here are some additional resources for accomplishing this:
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel
https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work


With your code, an attacker will not be able to forge a valid message for your system. Yet she can still copy a (valid) message you've created and paste it on any other tag or restore to a previous state.

This means that this is possible:

Restore the account balance (if it's what stored on the tag) to what was before the purchase (simply by copy the tag before purchase and restore after purchase)
Share with someone else account (if you leave your tag unattended, some attacker can copy it and paste it on another tag, impersonnating you for further purchase).

Please notice that even if you are checking the balance online with a database (per-tag) to limit case 1, you can't prevent case 2 with your scheme.

The 32bits password protection only prevents from modifying the content of the tag unless you know the password (since I doubt you'll use the password to set a "no-access" zone), but anyone with a simple $100 tool can capture the password when operating a valid tag since it's transmitted in clear (MITM here), so it's useless as I understand your need.

To prevent the kind of abuse above, you need a way that:

Does not transmit the password/secret key in clear text
Create a likely random (different for each access) session key for ensuring the reader and the tag are what they pretend
Use that session key to access / modify data on the tag

This is only possible with Mifare Ultralight C (or DESFire) tags (don't use Mifare Classic as their crypto is broken).

Typically, with such tag, you'll use the tag unique identifier to create a per-tag, per-sytem secret key. With this key, you'll authenticate with a block on the tag and store the balance/message encrypted with another key you're deriving from the tag UID. You should also rotate the keys, if possible after each authentication.

If authentication is valid, you're sure that the tag isn't cloned, and wasn't restored from a previous state.

So to make a clear diagram of the process:

  let M = message to store on tag
  let transaction = the current transaction counter you need to store in a database
  let Secret1 = some secret random value for your system (16 bytes for 3DES key). Depending on your security need, you might need to derive this secret from the reader's unique identifier.
  let Secret2 = some another secret random value for your system (16 bytes for AES key)

  When a tag is enrolled:
    let UID = tag UID
    transaction = 0
    let authKey = Hash(UID, Secret1, transaction)
    let msgKey = AES_CTR(M, Hash(UID, Secret2, transaction))
    change KeyA from default to authKey
    authenticate with authKey on some sector
    write msgKey
    store (UID, transaction) in your database

  When the tag is used:
    let UID = tag UID
    let authKey = Hash(UID, Secret1, transaction)
    authenticate with authKey on same sector
    if (authencation failed) reject tag or kill it, exit
    read msgKey from the sector's data
    extract M = AES_CTR(msgKey, Hash(UID, Secret2, transaction))
    if (M isn't good) reject tag or kill it, exit
    Perform your system's intended action, this gives M'
    increment transaction
    compute msgKey = AES_CTR(M', Hash(UID, Secret2, transaction))
    write msgKey to sector
    compute authKey = Hash(UID, Secret1, transaction)
    change authentication's key with new authKey
    update database's transaction count.

If you don't have a database (on the reader, or if the system is not online), you can't prevent tag copy and restore since the attacker could use a NFC tool to emulate a Ultralight C card and capture the content of the block when enrolling (even through they can't understand what's inside). This is high tech so depending on the value of the assets you can to protect, it might not make sense.

There is some feature with Mifare where you can store a value in a block and you can instruct the tag to increment or decrement it if you have the correct key.
It's trivial to implement this with the above pseudo-code, but this only work if the tag is storing a balance (understand: not for a message).

Now that you've the overview, let's answer your questions:

Ultralight C allow authentication, thus preventing MITM capture of password with a NFC probe (if used, obviously, else there's no advantage)
Password is moot. Unless you can control all your readers, that is, place the tag in a sliding tray, and slide it so it's read inside the machine with no space around for electronic gizmo, it's useless.
Authentication is required. Without a way to derive a secret session key, there is no protection from a MITM. For android, I don't know.
It's like comparing a truck with a transparent plastic bag. Both can store apples. Yet, the former is more expensive but you can do more things with it, like putting more stuff in it, locking the doors, etc... If you don't care about people seeing the apples and adding/removing them, use the plastic bag, it's cheaper.
There is no real advantage for your system to use DESFire or ICode here. You actually don't need additional storage space, and 3DES is secure enough to protect a cafeteria balance here. There is no economical sense to pay hundred if not thousand of dollars of computing power to try to break the $20 balance on the student cafeteria's account.

From a usability point of view, you can use an Android phone as a ISO14443-4 NFC tag (with random UID, so my scheme above needs to be modified).
DESFire is also ISO14443-4 compliant so if you go the Android's way of doing NFC, you can still sell and use DESFire tag for those without such phone & function.

Again, this requires a lot of development to get right, and I can't tell if it makes sense for you compared to a relatively simple Ultralight C system or a web based application for paying.


Jenkins malicious process identification

According to the information that you post on your message I will follow the next steps:

Drop the traffic of the process with iptables, at IP level, at process level, you have alternatives to do this.
Try to find the binary or script that correspond to the executed process, using lsof, also on you can use the information of /proc/
Check the parent of the process, this will give you information of which process runs the script.

Probably some other users will give you useful tips.


Dual Linux System with Whole Disk Encryption

You should create a single volume if you want the same password(s) to be valid for both installations, or two separate volumes if you want different passwords. In other words, create as many separate volumes as you need separate sets of authorized users.

The kernel and initrd of both installations need to be outside the encrypted volume. From a security perspective, it doesn't matter whether you keep the two /boot volumes separate or not.

If you do trusted boot from a TPM, watch out that the non-primary OS is also integrity-protected; I think in that case you should keep the two installations separate and register them independently with UEFI (but I don't have experience of UEFI to tell you what to watch out for).

Note that you may not need dual boot at all. You may well be able to implement your desired security policy by issuing separate accounts or by creating separate virtualized containers, each with its own root users.

See my answer on AU for the more technical aspects.


OpenPGP Encryption / Decryption Process Using GnuPG

The encryption and signature processes which take place on server A and server B protect the form data against unwanted eavesdropping and malicious (or accidental) alteration, from the moment they were encrypted/signed on server A, to the moment they are decrypted/verified on server B. This includes any kind of storage on A or B, and whatever transport medium is used between A and B. But note the following:

The encryption and signature say nothing about the data submitted by the client; as @mikeazo suggests in a comment, the submission process had better be protected as well.
Thanks to the signature, B can be sure that any message it received is "genuine" (it is really as it was when A signed it). However, B cannot know if he got all the messages; signatures say nothing about message which B never saw because the attacker intercepted them before delivery to B.
The signature covers only that which is signed, not any metadata that may be associated with it. For instance, the form data can be verified to relate to a given user only if the name of that user is part of the form data. Otherwise, an attacker would be free to swap encrypted forms around in A's database. Similarly, an attacker hacking is way between A and B could replay old encrypted message, so B cannot be sure that he got "the latest" form data for a given user unless that form data includes some kind of time stamp or sequence number.
Security is only relative to the secrecy of the involved private keys. It takes a bit of faith to believe that an attacker gaining access to A's database will not have access to A's private key.

So while your encryption+signature system does offer some useful guarantees, they may fail to cover everything that envisioned attackers may try. I invite you to formally write down, somewhere, the extent of the powers that you grant to the supposed attackers (that's the "attack model").

Apart from that, using GnuPG is a very good idea, in that using a homemade implementation, or, worse, a homemade protocol, would be a very bad idea.


Can the subdomains have different certificates from the main domain if I use HSTS includeSubDomains and preload?

Yes, you can use different certificates and change certificates as much as you want, as long as you keep using HTTPS. HSTS, preload included, does not restrict what certificates you can use. It only forces you to use HTTPS.

(HPKP, on the other hand, restricts what certificates you can use. But that is another story.)


How to avoid referer information leakage during password reset

Browser leaking links?

Here is a screenshot of my chrome settings:

You can see that the browser may:

query another service about whether the link is legit
query another service if the link has an error

I don't know the specifics, but that means you also have to worry about those services leaking the token before the user has a chance to visit the page or in case your webserver is misconfigured.

Password reset page

If you do not want to link referer information, do not include the link.
If you want to mitigate some effects, include a strong CRSF token in <input type="hidden"> ; that way even if the link is compromised, they still need a valid CRSF token.

Why not also require a cookie?

If, by any chance, you are using github to host your website code, do not put your config (e.g. value of SECRET_KEY used to generate tokens) online.


Why is "fhepfcelehfcepfffacacacacacacabn" a top DNS query from my devices?

That domain is an encoded form of the string "WORKGROUP". It is using a variant of hex encoding that uses the letters A-P, instead of the numbers 0-9 followed by A-F.

$ echo fhepfcelehfcepfffacacacacacacabn |
  tr a-p 0-9a-f |
  xxd -r -p |
  xxd

00000000: 574f 524b 4752 4f55 5020 2020 2020 201d  WORKGROUP      .

This appears to be a NetBIOS name, which is why it's padded with spaces to 15 ASCII characters, and then followed by a different character at the end as a suffix. The hex encoding is described in the NetBIOS-over-TCP/UDP Concepts RFC, called "first level encoding". Also, NetBIOS uses DNS record type ID 32 for its "name service" packets; that ID was later allocated to NIMLOC (ref), which explains that part of the log. However I'm not sure exactly what software on your machine is making this DNS query; if you're using Windows, it seems likely to be something at the OS level.

I don't believe the answer from NextDNS support is correct here about the source of this particular query—it is probably not coming from Chrome.


Hiding packets, requests, traffic from my PC through Ethernet connected to workplace network

A VPN is a solution to this problem, as is Tor (assuming correct configuration). With both of these methods, it is obvious you are using them, however all of your traffic is encrypted between you and some remote endpoint (VPN server, Tor node, etc.) such that nobody on your local network can see your final destination or data.


JSON through <script src=, how do you get the JS object in the rogue page?

See this question for more detail, but in short, tampering with the prototypes of Object and Array can let you read out the contents of any object as it's created. So an attacker doctors the prototypes, document.write's the script tag, and even though the JSON object is not saved, the attacker's instrumentation gets notified as each property is set and can make a copy.


make specially encoded template available for file uploads

Firstly, I don't think what that commenter posted is great general advice.

I'm assuming what they mean is try to validate some attribute of the file format you're expecting. For example, if you're expecting a .docx file you might validate that it's an archive containing a folder called /word/ and that directory contains a file called document.xml and that document contains some tag/markup either unique to your template or required by .docx files.

The idea is that it'd be difficult for an attacker to make a file which conforms to these requirements but is still malicious.

Frankly I think this would only work in certain very specific scenarios and I think most of the security would come from obscurity (ie. the attacker not knowing exactly what your validation criteria are).

The advice about assigning files a random name, not putting them in a publicly accessible directory, not giving them execute permissions, etc. is more important.


You can use Proof of Work to limit the speed at which brute force programs can try to login. This is a user-friendly alternative to CAPTCHA

Proof of Work requires the client calculate the prime factors of a very large number, and this takes time

Send the large number to the client. If they don't provide any answer, immediate NO. If they provide an answer, it's fast to check on the server. If they pass, let the login attempt proceed

You can also use a device cookie to bypass account lockouts. For example, if client C has previously successfully authenticated for user U, store an HMAC'd cookie on client C . Having this cookie lets that client bypass account lockouts for that username.


How to configure Burp Suite if system proxy is handled by websense and application can only be accessed through IE?

We recommend you perform testing from a system that you have administrative control over, so you can set the proxy settings. This could be a virtual machine.

If that's not possible, you may be able to set the proxy directly in the registry. There's some information on this question.

You may still need to set an Upstream Proxy within Burp, depending on the setup of the network you're on.


Why should anti-virus software scan on a file read?

Why should it scan on read, and not when the files are written on the
  hard drive?

Because this will cover the situation when the A/V software is installed after files have been written to the computer.

Also, as new viruses are discovered, they may be an existing threat on the machine that has not yet been detected due to the signature only being available in the latest version of the updates.


Why is Firefox (and only Firefox) reporting that my connection is insecure on multiple sites?

There is a lot to unpack so I’ll do my best here (based on some assumptions).

Firefox maintains its own certificate store which is likely the reason only Firefox is throwing these errors. Traditionally, SysAdmins will push out certificates through Group Policy, which works for both Chrome and IE / Edge but Firefox won’t trust it. I would imagine that your traffic is being intercepted by a transparent proxy server which is inspecting your traffic (note that looking at the certificate information will reveal whether or not this is a certificate that your work has pushed out).

Assuming again, but your work is probably explicitly not filtering financial website traffic — presumably to avoid any potential liability with doing so.

I have no idea why some load as plain text. This might be something to do with the proxying process.
EDIT: As Arminius astutely pointed out, pages loading as plain text is likely due to certificate errors happening with resources being pulled from third party domains. It is likely that the images and CSS are not loading as the cert errors from those domains prevent the resources from being transmitted.


What exactly does one get from a Nmap Scan?

The short answer is it gives you information and points to where you should spend your time next.

You sort of answered your own question, in that nmap does give you:

  all the open ports,services running on those ports, underlying OS and technology etc.

as well as the fact that those things are not firewalled off from the point of nmap scan.

With all of this information you can cross-reference vulnerabilities that may apply to such services, OSes, etc. Some might be current vulnerabilities with no easily-available patch, in which case you're in. Others might be older vulnerabilities, in which case you will have to test and see if the target box is up to date on patches or not.


Should one buy new hardware after a system compromise?

You must do risk management. How likely it is that you and your laptop have been personally targeted? The vast majority of persistent malware operates entirely in software, and formatting the disk is more than enough to remove all traces of it. Sophisticated, firmware-resident malware is extremely rare and unlikely to be a threat unless you have particular reason to think that you are at risk. It is possible to check for firmware-level malware, but it requires a good understanding of common x86 architecture, and access to hardware to read from the flash chips. At a minimum, you'd need SPI readers for the BIOS/UEFI, and JTAG probes for the hard drive firmware and related.

If you don't have any reason to think you're being targeted, just format and re-install.


How to Verify the Identity of the Caller of a Web Service

You can add an API_key to your authentication process - something that a user needs to request first thing from the server. This initial request can contain device specific information, application specific information and user identity bits. Generated API_key can be a cryptographic hash function of that data.

A server stores all the API_keys and link a key to a user (if you want).

Only requests that have valid certificate and API_key are authenticated. You can then only allow one simultaneous log on with a valid API_key to mitigate API_key sharing.


Are there potentential risks to allowing a PHP website MySQL User to have Create, Alter, and Drop Permissions

Unfortunately I'm not very familiar with PHP so I cannot provide any hint of how this could be specifically exploited from the code but I want to point out some other details.
From a security engineering point of view, you open a serious amount of attack opportunities. First of all, the reasons to avoid DROP are obvious. Apart from that, if an SQL injection does happen the user could have made a script that creates an infinite amount of databases and potentially DOS your system, a scripted attack using ALTER may also cause chaos in your database.
You can check some of those things in the backend but still granting too much power to a user

It's difficult to propose something without the source but why don't you  try to isolate the "dangerous" actions inside the server by passing the request to a backend verification and then have root or another privileged user alter the database?


Other than synchronizer token, is there any way of protection against CSRF using http headers?

Yes you could use something like the X-Requested-With header - this header cannot be passed cross domain without the server opting into this with the domain in question via CORS.

The synchronizer token pattern is still the recommended method by OWASP - one of the reasons is that there have been vulnerabilities in the past with browser plugins (e.g. Flash) that have allowed headers to be set that normally can't be set in the browser via JavaScript.

So for that reason I would recommend the synchronizer token pattern over checking headers, but at the moment of writing both are equally good. You never know if there's a Flash zero-day around the corner though.


Do I need to password-protect an "Electronic Copy" of health information given to a patient on e-media?

I just received a notice from Google telling me that since the Google Health service will close on January 1, 2012, I should download my data and close my account.  Before the download started, it asked me to confirm this message:

  You have chosen to download your profile as ZIP. The downloaded file will include all data in your profile, including PDF, CCR, CSV, notices as XML, and files. This may take a few minutes to prepare and download, so please be patient.

  Your Google Health profile may contain sensitive information, including health records. If you download sensitive information to a shared or unsecured computer or device, others might see it. You are responsible for protecting the information that you download, and for deciding with whom to share it.

  Are you sure you want to download a copy of your personal health profile to the computer or device you are using?

I downloaded and opened the file. The PDF files were not encrypted, and they contain my name and date of birth, which would qualify as PII (personally identifiable information), and PHI (personal health information).

Now I am not a lawyer (although I have played one on TV ... long story), but I have to ask: if Google doesn't password-protect a PDF containing PII & PHI delivered digitally to the patient, why would anyone else be required to do so?


Example of reflected client XSS which is not DOM based XSS

From those categorisations:

  Client XSS occurs when untrusted user supplied data is used to update
  the DOM with an unsafe JavaScript call.

(em mine)

Therefore for it to be client XSS, it has to involve updating the DOM.

Although, the article goes on to say:

  DOM Based XSS is simply a subset of Client XSS

I believe this is referring to the actual source being from the DOM rather than the server.

e.g.

foo.innerHTML = document.location.hash;

Rather than

foo.innerHTML = ajaxResult;

This is because the definition of DOM based XSS is as follows:

  DOM Based XSS is a form of XSS where the entire tainted data
  flow from source to sink takes place in the browser, i.e., the source
  of the data is in the DOM, the sink is also in the DOM, and the data
  flow never leaves the browser.

So reflected client based XSS which is not DOM based is where the data itself is from the server (reflected in the response from the HTTP request), but the code is rendered on the page via JavaScript.

Example:

Request:

http://example.com?name=<svg onload=alert(1) />

(Name would be % encoded, but I've left it unencoded here for clarity.)

Response:

<script>
var name = "<svg onload=alert(1) />";
$('#output').html(name);
</script>

<div id="output">
</div>

Takeaways

What is probably important when it comes to XSS is the following:

Any type of stored XSS is mostly higher risk than any form of reflected XSS. Browser XSS filters cannot stop them (except if a Content Security Policy is in place and is sufficiently locked down).
When an XSS updates the DOM in a reflected XSS attack, this bypasses browser XSS filters too (same caveats in regards to CSP).
Server reflected XSS  is less risky as it requires user interaction and there's also a good chance a browser XSS filter will block it.


How to tell if an email source is spoofed?

To be honest this looks fine. It would be helpful to see the mail itself.

The whole fcmb.com domain is valid. They are not listed on any blacklist.
Those IPs are all valid.
They use emailprotection by trendmicro. They have valid certs by GlobalSign issued for the hostingprovider of their website, Incapsula Inc.

Here is some information on the bank:

https://en.wikipedia.org/wiki/First_City_Monument_Bank

This is the procedure:

I start with those "received" fields and check the "from" values. In your case there is only one field.

We find lin-smtp.fcmb.com and 41.233.147.112  this is correct as lin-smtp.fcmb.com actually resolves to 41.233.147.112. You can check this with a reverse DNS lookup.
In spoofed mails they sometimes add false values here like a nonexistend domain or ip. But typically they only adjust the "Return-Path"

"Received-SFP" indicates they have a SPF record set on their domain. This technique is used to determine which sending addresses are allowed to send mails in the name of said domain.
Its whole purpose is to avoid spoofing.

The IP we found can be check for blacklist entries (i used Cisco Talos reputationcheck/ MXToolbox Blacklist lookup).
Usually spoofed addresses are only used for a short period because they get discovered.
We can make sure this IP has been associated with said domain for long enough, if we check passive DNS databases(Risk IQ).

as lin-smtp.fcmb.com is a subdomain of fcmb.com we can go on with that.
It brings up a web page that looks plausible. I searched for them and found their Wikipedia article.

I followed with another reverseDNS lookup against fcmb.com:

a records: 45.60.1.138 / 45.60.1.138 both belong to Incapsula Inc with ASnumber 19551 (the same company that issued the websites SSL certificate) they are actually known for webhosting and protection.

Maybe you should contact them.


This is from the PCI-DSS guideline:

  In order for a system to be considered out of scope, controls must be
  in place to provide reasonable assurance that the out-of-scope system
  cannot be used to compromise an in-scope system component, as . the
  in-scope system could then be used to gain access to the CDE or impact
  security of the CDE. Examples of controls that could be applied to
  prevent out-of-scope systems from compromising a connected-to
  orsecurity-impacting system include:

  Host-based firewall and/or intrusion detection and prevention system    (IDS/IPS) on in-scope systems that block connection attempts
  from    out-of-scope systems.
  Physical access controls that allow only designated users to access    in-scope systems.
  Logical access controls that permit only designated users to login to    in-scope systems.
  Multi-factor authentication on in-scope systems.
  Restricting administrative access privileges to designated users and    systems/networks.
  Actively monitoring for suspicious network or system behavior that    could indicate an out-of-scope system attempting to gain access to an
  in-scope system component or the CDE.

So in short having peering isn't an issue as long as you have strong control to segregate access to sensitive systems. If your RDS does not contain sensitive information but your PCI systems still require to read from the RDS, you can put rules in place that your PCI scoped systems can pull information from the RDS but the RDS itself cannot push information. If your RDS is not a CDE, then I suggest you move it out. Ideally you have three tiers of network, where one is your CDE, one is a middle ground for information exchange and one is your more "general" environment. This will make it easier for you to segregate and apply monitoring as well.


MitM-Position with bridged network and iptables

Thanks to @whitewinterwolf I found a solution to the problem.

I had a wrong conception of how this proxy was supposed to work.

If you're looking for a c&p-solution, please see below.

# bridge setup as before
ip l a name br0 type bridge
ip l set br0 up
ip l set eth0 up
ip l set eth0 master br0
ip l set eth1 up
ip l set eth1 master br0

ip a a 10.0.0.2/24 dev br0
ip r a default via 10.0.0.254 dev br0

# now ensure that netfilter works on the l2 bridge
modprobe br_netfilter
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables

The reason it didn't work before is that iptables does not normally work on the second layer of the OSI model but on the third. Bridges are on the second layer and therefore don't care about PRE- or POSTROUTING activities. The br_netfilter kernel module enables exactly that. Afterwards you just have to turn on the functionality.

Networking is hard but fun.


Evil Twin Access Point Secured-Unsecured

I've already answered on how to clone AP (merge with the original on a wireless network list) in here I think.

If you're evil twin is an Open Network (waiting for the user to mistakenly selecting it manually from the network list), you would have to keep sending deauth frames until the reconnection time times-out.

If you want to automatically accept the request of authentication (which will be passed to the RADIUS-AAA server) from the client you need to have exactly the same settings on the AP.

Higher signal strength (There is a parameter that says which AP is better to connect "roaming aggressiveness")
Same ESSID (The name of the network the probe requests look for or the beacon the AP emits)
Encryption algorithm (WPA2, judging by the tag on your question)
The Cipher (CCMP)

Which roughly translates to this on the hostapd.conf (These are SOME parameters)

auth_server_addr=192.168.0.1         // RADIUS SERVER (Enterprise / 802.1x)
auth_server_port=1234                // RADIUS SERVER (Enterprise / 802.1x)
auth_server_shared_secret=verySecret // RADIUS SERVER (Enterprise / 802.1x)
wpa_key_mgmt=WPA-EAP                 // RADIUS SERVER (Enterprise / 802.1x)
ieee8021x=1                          // RADIUS SERVER (Enterprise / 802.1x)
wpa=2                                // Encryption Algorithm (WPA2)
wpa_pairwise=CCMP                    // Cipher (CCMP)
ssid=evilTwin                        // ESSID
rsn_preauth=1

Here's the link where I took this example from (for further knowledge too).

Now, this obviously will fail at some point because you need the RADIUS server, you're talking about 802.1x, so you also need to configure the eapol-config file (If you're using freeRADIUS) which changes everything when you choose one of the 22 supported EAP methods (EAP-PEAP, EAP-TTLS, EAP-TLS, EAP-MD5, EAP-FAST, etc.)

  Because the PSK generated from the fake AP would be different from the one generated by the client.

The key used for data encryption is called PMK, and it's dervived from the TLS Masster Secret in EAP-TLS, here you can find some more infor specifically for EAP-TLS

I hope this answers your question because it's still missing what you want to achieve and everything about the RADIUS server.


Are compiler options relevant to C# security? If so, which options?

First off, C# and .NET can't do deterministic builds.  See the official response here.

Post compile you may want to obfuscate your code or encrypt it.

PDB files mean your exe can be debugged. Follow these directions to prevent PDBs from being created when in release mode.

Note that deploying in Release is different than debug, and run time debuggers may have a hard time reading it (a good thing)

Consider signing your code with Authenticode

Consider loading only strong named assemblies


how much time does it take to fully destroy a deleted video from SD card?

When you delete something from an SD card (or most mass storage media) it doesn't actually get deleted. The space on the card where the file is stored is simply marked as unused and will be reused when space for a new file is needed.

Whether or not the file can be restored with data rescue software depends on how much new space was needed in the meantime for creating new or enlarging existing files.

If there were no write operations on that SD card after the file was deleted, then it is very likely that it can be recovered. But if someone created a couple new files on the card in the meantime, then there is a good chance that some or all blocks of the deleted video were overwritten.


Looking around at other financial services providers, asking for 2 PIN digits only once other security information has been entered is a fairly common pattern. Are there any significant benefits from this approach compared to asking for all the information on a single screen?

I'm assuming that the other systems you've looked at only tell you whether any of your details are incorrect after the second step, and do not disclose which part of the credentials were incorrect, which is good.

Yes there are significant benefits, because then the index of the digits are only asked for when it is determined which username it is that is attempting to authenticate.

Say an attacker had somehow got some partial details of an account (e.g. by shoulder surfing). Let's say they know the 2nd and 3rd digits of the PIN.

If the page asked for all the details on one page (username, password and two digits from the PIN), the attacker could simply refresh the page, clearing cookies each time, until the PIN prompt was for the 2nd and 3rd digits of the PIN.

Using the two step approach, the digits asked for can be remembered by the system. e.g. for username "foo" we asked for the 1st and 4th numbers - we will not ask for any others until these have been entered correctly. The system would also have to remember the digits asked for for invalid usernames to prevent a username enumeration attack where different usernames can be tried twice to see if the same digits are requested. You might also want to artificially refresh these digits after a set number of days to simulate a successful login (otherwise an attacker would know that the account is invalid or dormant if it always asked for the same two digits on attempts days apart).

The other approach would be to ask for all the digits of the PIN on the same page, but banks don't like doing this because of shoulder surfing and also phishing sites can easily mimic these pages and capture all information in one go (although I'm not saying that the stepped approach would necessarily prevent these sort of attacks).


How to have Thunderbird include a root certificate?

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a big security breach, similar to sending your banking coordinates to every phishing attempt you receive.

Distribution of root CA is assumed to be performed "out-of-band" and with a secure medium (for instance, hardcoded in the "Thunderbird" software package which you already assume to be trustworthy, since you let it read and write your emails). Distributing root CA by email strikes me as... less than optimally secure.

The underlying format for S/MIME, i.e. CMS, lets you store whatever certificates you want in a SignedData element (this is not a chain but a big unsorted bag of certificates and other objects). However, Thunderbird has a default behaviour of just putting the certificates for the signer's chain, excluding the root CA; to my knowledge, this is not configurable, and I cannot blame it because including the root CA would make little sense -- see above.


AES encryption (in Java) of different JSON strings always produce same encrypted string as result. Why?

Since I can't comment.
I tried the code snippet you gave us, by adding this method:

public static void main(String[] args) throws Exception
{
    String[] plain = new String[] {
            "{\"a\": \"b\"}",
            "{\"a\": \"n\"}",
            "{\"a\": \"k\"}",
            "{\"a\": \"pzfovvs\"}",
            "{\"a\": \"bqwuvck\"}"
    };
    for (String s : plain) {
        String enc = encrypt(s);
        String dec = decrypt(enc);
        System.out.println(s + "\t" + enc + "\t" + dec);
    }
}

And the result is, that I can't reproduce the issue. The output is this:

{"a": "b"}  /P80Sou3+dGozWw7eVowRQ==    {"a": "b"}
{"a": "n"}  ht8KPm8KzZE9czjX2Jmu4w==    {"a": "n"}
{"a": "k"}  rFHzmbC3l6zjT4XP6Vhing==    {"a": "k"}
{"a": "pzfovvs"}    RhJi+SasO6tzvLf6yaDTgYhPWMFDIUVaS10zLek43/M=    {"a": "pzfovvs"}
{"a": "bqwuvck"}    S/H0I5qQKT9Fo5zitUzqKohPWMFDIUVaS10zLek43/M=    {"a": "bqwuvck"}

It also looks like the implementation is correct.

I used the jdk-13 to test this. So either the Java Version you are using is bugged, or for some reason you don't write the correct String to your encrypt method and instead are always supplying the same String. Eitherway the snippet you have sent works correctly.

Greetings


PKCS12 password stolen - what's the security impact?

The password unlocks the encrypted private key of the certificate, so an attacker always needs both, the PKCS-file and a password to successfully use the certificate.

Please mind, that most humans tend to use the same password for more than one purpose, so there are chances that a other person can make his way to the pkcs file with this password (for example a logon on a file server or similar).

How risky this is depends on more factors:

--> For what is sites is this certificate? Are more SANs specified - if yes how critical are the webservers who host this sites?

--> In worst it´s a wild-card certificate. This would give an attacker the chance to issue trustful sites for everything ending with your company name (evil.corp.com, trustme.corp.com,...)

--> How is revocation done in your PKI Infrastructure? Does every single device who checks certificates in your environment do revocation right? There is still the issue that most browsers tend to accept certificates if the CRL can´t be contacted so even that is no 100% solution.

and so on...in most cases you should definitly revoke the certifcate, generate a new private key on the server who needs the certificate and only keep it there nowhere else..


You do not encrypt with ECDSA; ECDSA is a signature algorithm.

It so happens that an ECDSA public key really is an "EC public key" and could conceptually be used with an asymmetric encryption algorithm that uses that kind of key; e.g. ECIES; or it could also be used as one half of a key exchange algorithm like ECDH, resulting in a "shared secret" than can then be used with a symmetric encryption algorithm.

However, this is not necessarily a good idea:

Using the same key pair for both signing and encryption risks triggering some unwanted interaction between the two algorithms (e.g. the receiving party, upon computing a decryption over an attacker-controlled message, might unwillingly leak information that could lead to a signature forgery). This kind of interaction is not well studied.
Signature keys and encryption keys tend to have distinct lifecycles: generation, storage, backup... should not be handled the same way for both kinds of keys. By using the same key for signatures and encryption, you thus do things suboptimally in that regard.

A safer way to do things is to have each party own two key pairs, one for signing and one for encryption. Possibly, the owner signs his encryption public key with his signature key, so that people who know his signature public key may verify the truthfulness of his encryption public key.


How to responsibly disclose a vulnerability in a widespread algorithm?

The grace period is proportional to the complexity and time it would take to remedy the vulnerability. For example, take this thread on reporting a security vulnerability about a trusted certificate authority, a pretty serious problem with far-reaching consequences. One poster explains the reporting protocol well:

  The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue certificates, publish security bulletins, etc, before you go public with your findings. The intention is that at the end of the negotiated period you get your public recognition, but your going public can't do any more harm - if the vendor has done their job properly.

I imagine, in your scenario, that the vulnerable vendor would (hopefully) relay the information to others. You could also contact CERT, who is trusted and has experience in dealing with such matters on a large scale. In a similar thread to the one I linked above, there's this:

  You should let the developer(s) know privately so that they have a chance to fix it. After that, if and when you go public with the vulnerability, you should allow the developer enough time to fix the problem and whoever is exposed to it enough time to upgrade their systems. Personally, I would allow the developer to make the announcement in a security bulletin in most cases rather than announcing it myself.

We can probably agree that it would be a bad idea to go public immediately, because that would leave the door open for exploitation. So privately notifying them is the best way to go. In the meantime, they would probably fix it, upgrade, or switch to something else. What other reasonable options are there?

Finally, there are real-world cases of cryptographic vulnerabilities, and those algorithms were widely used. One example is Dual_EC_DRBG, an elliptic curve based algorithm, which was used for quite some time before being revoked due to security issues. I got schooled on it in this thread.


Determine if helloworld.msi is malicious

This does not look legit at all. These are the points that indicate to me, that something fishy is going on:

MsiInstaller with some Russian HTTP-only-domain
The domain name is not meaningful.
The strange port 280 is used for HTTP.

I can think of no legit reason for this log entry.

I'm not familiar enough to prove it, but I'd consider your computer as compromised.
I'd therefore recommend to reinstall it from scratch and change all passwords of services, you accessed with this computer.
This procedure might be overkill, but as there is no way of telling what this software has been doing lately, you'd be on the safe side.


How much safe is "the cloud" ? What is the simplest and safest approach in storing everyday personal data?

The answer is very complex and depends on many factors:

which kind of information would you like to store in a cloud,
how much you care about them,
how much you will be affected in case of those data disclosure,
how much money and time would you like to spend on your data storing solutions.

Personal data sounds like important stuff to me, so I would suggest you to not store you data in one of big-company, free services, such as Dropbox or Google Drive. Maybe it seems to be a bit too preventive, but big organisations are well known for their curiosity of our data. So I would choose one of commercial services, usually they pay more attention to security. But of course not always.

The second thing is to encrypt your data, with use of some well-known and tested tested solution. Most security-related people consider TrueCrypt as fine tool. If will choose some other tool remember to check which kind of algorithms it use. At the moment AES-256 (symmetric), RSA-2048 (asymmetric) and SHA-512 (hash) are consider secure enough.

If you have plenty of time, some Unix skills and a bit of infrastructure you can also install you own cloud with use of such software as ownCloud or SparkleShare.

EDIT: I just found a another similar software called SeaFile, they just release version 2.1.

There are also solutions called Virtual Private Cloud, which run partially in your infrastructure, but usually they are for commercial use. Please see the list of virtual private cloud providers.


How can a major UK website detect usage of a UK VPN on an incognito tab outside the UK?

Your first three explanations, from the perspective of a webadmin, seem a bit too cumbersome to be worth the bother.

Have you tried looking into WebRTC leaks? They're a popular vector for deanonymizing VPN users. Either disable WebRTC in your browser's about:config (or equivalent), or setup a firewall to exclusively allow network access through the VPN tunnel. For example, CDNs are based on location, so leakage could give your true location away.

It's also possible to detect VPNs in general based on their reverse DNS. VPN providers usually have a set of hostnames that turn up upon an rDNS query that can be used to detect VPN usage (and even the exact provider).


Exactly why is it not possible to "drop-out" of TLS 1.3 proxy inspection?

In TLS 1.2, the master secret, which is used for deriving keys, is derived from the pre-master secret and some additional data.  With RSA key exchange, the TLS middlebox can simply act as the client and send the pre-master secret that was derived to the remote server.  With Diffie-Hellman key exchange, the TLS middlebox sends non-prime parameters (which are usually insecure) based on the server's key exchange parameters such that the computation of the pre-master secret is the same.  As Z.T. mentioned, this is described in the Triple Handshake paper.
In TLS 1.3, the keys are derived from the master secret and a hash of the handshake using HKDF.  Because HKDF is a PRF (a pseudo-random function family), it is functionally impossible to generate the same set of keys when the handshake hashes are different (which they must be if the TLS middlebox and the server present different certificates), even if the keying material is the same.
This was done intentionally for two reasons:

This makes it much harder to conduct any sort of attack on TLS, since the entire handshake, as well as the actual key exchange, influence the derived keys.  It's no longer possible to specifically craft keying material to intentionally derive the same set of traffic keys, which has been used in previous attacks.
Many folks involved in TLS do not like middleboxes, since they rightly see them as an intentional attack on the end-to-end security of the protocol, and this makes them more difficult to implement.


Detecting or preventing process memory injections on Windows (anti-hack)

Ooooohh I love questions like this.

Right, first up:

  we are hosting a game server

Bam, there you go. If the client must send the state update back to the game server before this is pushed out to other clients, you have a chance to analyze the game state for changes. This means you can detect anomalous patterns. So for example, if you suddenly see a massive change of value in gold, you can then shut that user out of the game.

There's many statistical approaches you can take. Aside from the obvious "huge change" or "impossible action" you can apply more long term solutions - such as gold over time. Assuming I know about the "don't add massive amounts of gold to my character" trick I might increment gold in safe amounts over time. Great, if I always push the edge. However, that constant increase won't correlate with the equivalent gold earned in genuine consistent gameplay, so... again, detect and shut the account down.

The key here is that these are things you can do on the server side that the end user can do nothing about, even if they've manipulated the game state.

Now, onto your Win32 side questions. First up, I don't think WriteProcessMemory is a particularly valid call for any DLL to make, with the exception of debuggers (which will replace instructions in code - this is how breakpoints set by debuggers work), however, there's no way you can reliably replace this for every call on the system without writing what is effectively a rootkit - i.e. you'd affect everyone, not just yourself. So this isn't really an option.

One thing you could do - and it's no mean feat - is to periodically check your own executable memory for modification. For more, see Tamper Aware/Self Healing Code on codeproject. Basically, periodically invoke this and crash the game if you detect any modifications.

You might also consider code signing - it's not ridiculously expensive, and it does provide a built into windows way of preventing offline executable modifications.

If you store saved state locally, you might consider saving checksums and sending these to your server accounts. No, this is not bulletproof, but it adds extra complexity.

If you're going to implement any of these features, you're going to need to raise the barrier a bit and make it hard for the cracker to disable, skip or otherwise work around your protection mechanisms. Let's be clear - if someone is determined enough, you're done for, but you can at least make their lives very painful.

The top articule for anti reverse engineering on my reading list is also from code project. The guide is very thorough and should give you an excellent grounding in exactly what you can do to confuse and otherwise upset debuggers. I'll walk through one of them, which I think is fantastic:

 SetUnhandledExceptionFilter(UnhandledExcepFilter);
 __asm{xor eax, eax}
 __asm{div eax}

This is evil. Basically, as the article explains, the UnhandledExceptionHandler is called on a non-debug process as the handler of last resort; however, in this case we deliberately clear eax, then divide by zero. That'll cause a processor fault, which the OS then sends back to the executable's exception handler - only if there's a debugger attached. If there is a debugger attached, the debugger gets notified and the executable exits.

Of course, it is fairly easy for an attacker to replace div eax with one or more nop instructions or something, which means execution will just slide over, but a little self verification picks that up easily enough.

So, in conclusion then:

My first advice would be to try to detect cheats on the server side. Here, you hold all the keys. You could even introduce these changes "dark", that is, check and see who is cheating, then analyse their states to see if it works, without cutting them off.
Then, I'd attempt periodic self verification in several forms:

In memory, as much as is reliable, of the executable.
In memory, as much as is reliable, of critical data structures.
The executable on disk, too.

Finally, I'd read that reverse engineering guide top to bottom - and see what you can apply to your executable. I realise you said you can't modify your executable, but honestly unless you do so, you're likely to be up against it. After all, a second "watcher process" can just be killed by an attacker.


How to tell if my OpenPGP public key is self-signed?

OpenPGP Self Signatures

Self-signatures are applied on user IDs and subkeys, and make it obvious to anybody else that the ID or subkey really  have really been added by yourself. User IDs and subkeys not selfsigned could have been added by anybody and uploaded to the key servers.

Usually, self-signatures are created automatically by GnuPG, so you don't need to care about anything.

Checking for Self Signatures

Using the terminal, checking for self signatures is achieved very easily. Self-signatures are listed among the others, so all you need to do is filter for user IDs, subkeys and their respective next lines (which should contain the self signature).

gpg --list-sigs [key-id] |grep -EA1 '^(sub|uid)'

If you have a user ID or subkey which does not have a signature issued by your own key in the next line, you still might have to look through the whole output following this user ID/subkey -- so look through the whole gpg --list-sigs [key-id] output, find the subkey, and see if there's a self-signature line below.

In the example output for my own key, you can easily see that each uid or sub line is followed by a signature issued by the primary key itself, confirming all of them are self-signed.

$ gpg --list-sigs a4ff2279 |grep -EA1 '^(sub|uid)'
uid                            Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sig 3        0x4E1F799AA4FF2279 2012-12-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
--
uid                            Jens Erat <jens.erat@fsfe.org>
sig 3        0x4E1F799AA4FF2279 2012-12-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
--
uid                            Jens Erat <jens.erat@uni-konstanz.de>
sig 3        0x4E1F799AA4FF2279 2012-12-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
--
uid                            Jens Erat <jabber@jenserat.de>
sig 3        0x4E1F799AA4FF2279 2012-12-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
--
uid                            Jens Erat <email@jenserat.de>
sig 3        0x4E1F799AA4FF2279 2012-12-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
--
uid                            [jpeg image of size 12899]
sig 3        0x4E1F799AA4FF2279 2012-12-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
--
sub   2048R/0x9FF7E53ACB4BD3EE 2013-01-23 [expires: 2023-01-21]
sig          0x4E1F799AA4FF2279 2013-01-23  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sub   2048R/0x5C88F5D83E2554DF 2013-01-23 [expires: 2023-01-21]
sig          0x4E1F799AA4FF2279 2013-01-23  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sub   4096R/0x8E78E44DFB1B55E9 2014-03-26 [expires: 2017-03-25]
sig          0x4E1F799AA4FF2279 2014-03-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sub   4096R/0xCC73B287A4388025 2014-03-26 [expires: 2017-03-25]
sig          0x4E1F799AA4FF2279 2014-03-26  Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sub   4096R/0x382D23D4C9773A5C 2014-11-22 [expires: 2016-11-21]
sig     P    0x4E1F799AA4FF2279 2014-11-22  Jens Erat (born 1988-01-19 in Stuttgart, Germany)


AWS allows you to set budgets, and alarms based on your current rate of spending. Those would be useful to control your spending. In theory, you could also set billing-based automation to start scaling down services to avoid a $10k bill at the end of the month.

AWS Budgets Tutorial

If your spending alarms go off, then you'd take a look and see why your costs are abnormal this month and determine what needs to be done to mitigate the attack. At that time, your actions will depend on what's driving your costs up.

It may be difficult to differentiate whether the costs are legitimate use or an attack. Following standard threat modelling practices will help you to identify parts of your application susceptible to this type of attack. In particular, try to limit the ability of unauthenticated users to access parts of the application that are resource intensive.


Storing API tokens safely on Android to identify developer

Have you considered a two-step process, where

A developer authenticates on your server, which will reply with the token
The token is then used for all subsequent sessions, and expires after a certain time of your choice

All of the above is done in the app. The session token is stored normally but given its short lifespan it is less of a crucial bit of information.

This allows you to:

Revoke someone's access e.g. if they haven't paid for the service
Keep track of usage
Allow a developer to "log off other sessions" in a manner similar to what Gmail does
Let a developer have more than one token


Different Results When Testing TLS Using CDN77

There is an inconsistent setup of the site. Currently a DNS lookup for the site returns 5 IP addresses and each DNS lookup returns these in a different order (i.e. DNS based load balancing), which means that multiple attempts to reach the site might actually reach different servers.

These servers seems to be configured differently. From the SSLLabs report:

 172.104.210.88       Grade B
 172.104.22.58        unreachable
 45.79.155.107        Grade A+
 172.104.16.205       Grade A+
 172.104.219.176      Grade A+

And SSLLabs also adds a big warning

  Warning: Inconsistent server configuration

The A+ grades are for servers which have TLS 1.3 enabled. The grade B is for a server with no TLS 1.3, incomplete certificate chain and broken HSTS policy.

So it looks like that you've properly configured some systems but not others. Given that both www.waylisting.com and waylisting.com return the same 5 IP addresses but likely in different order it might happen that the testing can see different results for both domains, depending on which of the servers they actually end up testing.


Security benefit / purpose of signature on self-signed certificate in trusted store

Your assumption is true: certificates in the trust store are trusted only because they are in the trust store and not because they are signed by somebody (usually themselves, i.e. self-signed). That's why it is also not seen as a problem if there are certificates in the trust store which still have a SHA-1 signature, since this signature does not add any security anyway in this case.


Can an attacker make in-app-purchases of my products in their app?

Your scenario where an attacker exchanges a valid receipt for secret data can be mitigated if instead of the server sending the secret in reply to a receipt, it delivers the secret to your app through other means. Apple's Push Notification services are a good solution, as they tie your server to your own apps (no other apps can receive your notifications, and your server can't send notifications to other developer's apps even if it wanted to, because the client certificate it uses to talk to Apple only allows it to send messages addressed to your own apps).

When your requests the secret data from the server, it sends the receipt as well as its unique device token that allows you to send push notifications back to it. The server then sends the secret data as a push notification. If size is an issue it can send a secret key that fits in the notification's payload, and the app then downloads the actual secret data by presenting that key in a subsequent request. An imposter app would not be able to receive the push notification because even if it submits its own token, Apple will not allow your server to send a notification to that app since it's from a different developer.

Finally, one question comes to mind, why are you doing this? If the secret data contains info about other users, then this is your main problem. Instead of trying to protect that secret data (which you can't from someone who has physical access to the device), just make sure that data doesn't contain anything sensitive about other people, and let the user do whatever they want with their data. If it's for DRM, keep in mind that tons of people have tried and failed, and no matter how smart you are, you cannot do the impossible. Why not focus your efforts on delivering an awesome experience to encourage people to pay instead of copying your content?


Should we encrypt all REST API calls from a mobile device?

Considering that TLS is in place with a solid configuration (i.e. certificate pinning), which I find no reason not to, you'd need to work out the business risk you're trying to mitigate by encrypting this information.

Ask yourself, what would you gain by doing this? What type of attack vectors are you mitigating?

How are you going to generate, distribute and manage keys, where is the code and keys that encrypt/decrypts the data? What happens when (not if) the keys are extracted [i.e. will you be using the same key for everything?]?


What is a typical defense mechanism/setup against flooding back-end sql calls?

The database part of this is largely irrelevant, as a non-insignificant portion of your load will be on your web server rather than the database.

There are four common ways to implement rate limiting:

Perform rate checks against the user context, client IP, and other information within the application. This will allow more granular control of what types of requests you want to limit, and from who, but has the downside that the request must've already hit the web server and application in order for the checks to be performed.
Perform rate limiting on a host-based firewall, such as iptables. This allows you to reduce the load on your web application server daemon and any backend resources, but doesn't (trivially) allow you to make rules around which requests should be limited in different ways, as it operates at the transport layer (TCP/IP) rather than at the application layer (HTTP).
Install an appliance in front of the web server which performs deep packet inspection (DPI), or acts as a web application firewall (WAF). These are often called Layer 7 Firewalls or "full stack" firewalls, as they are designed to operate on application layer content (e.g. HTTP/HTTPS) as well as lower layers. You could argue that they fall under the umbrella term of Intrusion Prevention Systems (IPS), at least in terms of inline configuration. These can be very useful for terminating unwanted content before it even hits the target server, and can be very powerful, but have the downside that you usually have to put a lot of configuration work in, or buy an applicance.
Use a "security as a service" (SaaS) product in front of your server, which is designed to mitigate attacks such as flooding and DDoS. An example of this is CloudFlare. These aren't usually directly designed to prevent the exact types of attack you mentioned, but are pretty good at blackholing malicious automated traffic and DoS attacks.

These methods are not mutually exclusive; in fact, a combined approach is often the most effective.


Getting more information about a PGP Signature

Try to use gpg commandline:

$ gpg -vv
gpg: Go ahead and type your message ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBBABCAAGBQJYnkPxAAoJEBFjzYGyXBOsXRoH/3O4bwKK45aUN+m0N4jsZ+n5
W8R/aGti/llvJ62tHBCO5BIp/pp+b1Gdv99xtnJXHu/f0TqPYj+fwq4vfaorNTtA
Vtq8MaMesw1OWZEfu/lyjNOwdg81FUlYkw0Bjo3H/MxWjWYUiHmJo+OGriyf5dv/
433ZqitZMxLHCfZsuoU5teZ0BPUSoNjF6hOFK3ZI7QXsgYUyohzW2goy9bDVCKRq
e73CHpnMKCrnDc+/4+sK349bD/cZp6/c0T8b7cBCeBGGilPD6ovJUQE5vhGTKnJM
lgyxhA87tw9wqFwpZXDr0nzOP+MFfE9WRGecVYZ9G+LP/biefSe5iWRaPIcZIi0=
=qUHb
-----END PGP SIGNATURE-----gpg: armor: BEGIN PGP SIGNATURE
gpg: armor header: Version: GnuPG v2
:signature packet: algo 1, keyid 1163CD81B25C13AC
    version 4, created 1486767089, md5len 0, sigclass 0x10
    digest algo 8, begin of digest 5d 1a
    hashed subpkt 2 len 4 (sig created 2017-02-10)
    subpkt 16 len 8 (issuer key ID 1163CD81B25C13AC)
    data: [2047 bits]

As you can see, the signature can be decoded. Without the signed data however I can´t give you more information, specifically if the signature is valid. I do not find the issuer/signer on https://pgp.mit.edu/

Try to paste the whole message including signature into gpg -vv and see if it gives you more information.