OFB and CTR turn the block cipher into a stream cipher. This means that care must be taken when using them, like for RC4; reusing the same stream for encrypting two distinct messages is a deadly sin. OFB is more "delicate" in that matter. Since OFB consists in encrypting the same value repeatedly, it is, in practice, an exploration of a permutation cycle: the IV selects a point and OFB walks the cycles which contains this point. For a block cipher with block size n bits, the average size of a cycle should be around 2n/2, and if you encrypt more than that, then you begin to repeat a previous segment of the stream, and that's bad. This can be a big issue when n = 64 (e.g. you use 3DES). Moreover, this is an average: you can, out of (bad) luck, hit a smaller cycle; also, if you encrypt two messages with the same key but distinct IV, you could (there again if unlucky) hit the same cycle than previously (only at a different point).

The bad point of OFB is that it is hard to test for these occurrences (if the implementation includes the necessary code, it can test whether these unwanted situations occur, but this cannot be done in advance, only when part of the encryption has already been done). For CTR, things are easier: CTR is encryption of successive counter values; trouble begins when a counter value is reused. But a counter behaviour is easy to predict (it is, after all, a counter) hence it is much easier to ensure that successive messages encrypted with the same key use distinct ranges of counter values.

Also, when encrypting with CTR, the output begins to be distinguishable from pure random after about 2n/2 blocks, but that's rarely lethal. It is a worry and is sufficient to warrant use of block ciphers with big blocks (e.g. AES with 128-bit blocks instead of 3DES and its 64-bit blocks), but that's a more graceful degradation of security than what occurs with OFB.

To sum up, don't use OFB; use CTR instead. This does not make CTR easy to use safely, just easier. To avoid botching it, you should try to use one if the nifty authenticated encryption modes which do things properly and include integrity check, a necessary but often overlooked component. EAX and GCM are my preferred AE modes (EAX will be faster on small architectures with limited L1 cache, GCM will be faster on modern x86, especially those with the AES opcodes which were defined just for that).

To my knowledge, CFB does not suffer as greatly as OFB from the cycle length issues, but encrypting a long sequence of zeros with CFB is equivalent to OFB; therefore, it seems safer to prefer CTR over CFB as well.

Almost all block cipher modes of operation have trouble when reaching the 2n/2 barrier, hence it is wise to use 128-bit blocks anyway.

Note: CFB and OFB have an optional "feedback length". Usually, we use full-block feedback, because that's what ensures the maximum performance (production of n bits of ciphertext per invocation of the block cipher). Modes with smaller feedback have also been defined, e.g. CFB-8 which encrypts only one byte at a time (so it is 8 times slower than full-block CFB when using a 64-bit block cipher). Such modes are not as well supported by existing libraries; also, small feedback loops make the OFB issues worse. Therefore, I do not recommend using CFB or OFB will less than full block feedback.

As pointed out by @Rook: CBC mode, like ECB but unlike CFB, OFB and CTR, processes only full blocks, therefore needs padding. Padding can imply padding oracle attacks, which is bad (arguably, a padding oracle attack is possible only if no MAC is used, or is badly applied; the proper way being encrypt-then-MAC). For this reason, padding-less modes are preferable over CBC.

This leads us to a clear victory of CTR over other modes, CFB being second, then CBC and OFB in a tie, then ECB (this is a bit subjective, of course). But, really, use EAX or GCM.


Auditing and alerting is the general approach to insider threats.

If you make sure that activity on sensitive systems is heavily logged and monitored, you dramatically increase the difficulty of subverting those systems.  Typically, you'd log and alert on any logons, and maintain an audit log of all actions taken on the system.  To protect those logs from tampering, you send them to write-once media or another system that users of the sensitive system don't have access to.

Another effective, relatively cheap approach to the problem is the four eyes principle (requiring two people to oversee a given action).

Lastly, if you're worried about the integrity of your code, (or other files) you could always utilize code-signing.  Attaching a cryptographic signature to whatever it is you're worried about being modified would give you a very high degree of certainty that the code isn't modified without authorization (assuming, of course, you get the PKI for that signing system setup properly).


It's generally unnecessary. If you grew up in the days of Windows 2K or XP, you're probably thinking of a firewall as something necessary to protect the vulnerable innards of the OS from various malefactors on the Internet, but macOS (and modern versions of Windows) just don't expose their innards in the first place. Turning on the firewall sort-of adds a layer of protection, but it's protecting exactly zero exposed services, so it's kind of irrelevant.
Ok, I'm oversimplifying a bit. There are some services that macOS exposes by default, but they're things that're kind of needed for local network operation, like service discovery and name lookup (both Apple's preferred Bonjour/mDNS, and Windowsey NBNS), so the firewall lets them through anyway. If you click Firewall Options, it has an option to "Block all incoming connections" ... "except those required for basic Internet services, such as DHCP, Bonjour, and IPSec."
What the macOS firewall really does is give you a layer of administrative control over which programs are allowed to provide (/expose) services on your Mac. My favorite example is old versions of MS Office programs that opened ports so they could communicate with other instances on the local net to look for duplicate serial numbers. It doesn't tell you it's going to do this, or (of course) allow you to turn it off, and who knows how secure it is. But with the firewall on, that will ask if you want to allow it, and if you don't, the firewall will block incoming connections to that software.
So the real point is: do you trust the software you're running? Do you trust the software your kids are running? If not, the firewall is for you. However, the default is to trust anything built in (e.g. services turned on in the Services preference pane) and signed programs (enh...). Take a look at that Firewall Options dialog, and change anything you don't like.
BTW, in my experience the "Stealth mode" option mostly makes network troubleshooting harder, but if you aren't into network troubleshooting you might be ok with that.
BTW2, one thing the built-in firewall doesn't do is filter outgoing connections. If you want control over which programs are allowed to connect out, look at third-party options like Little Snitch and LuLu.


Security implication if android app can be installed on emulator

It is unclear what kind of security requirements you have in the first place and thus it is unclear if your security measures are sufficient or not.

Fully protecting against a malicious user using your application is not possible as long as you are not able to fully control the device of the user. This risk includes running the application on emulators but also includes running it on rooted or otherwise tampered device - and not all of this will be detected by whatever root detection method you use.

Instead you need to design your application so that a malicious user cannot do any harm to you or to other users but only to himself. This for example means having user specific secrets in the application and not using global secrets. This also means that you should not trust anything the application reports but instead verify if this make sense (i.e. not trust any self-reported high score in games or similar).


What Adnan says about ciphertext indistinguishability is correct, this can be a hard problem, the only clue you have is "Salted__" string which is how OpenSSL distinguishes salted and unsalted encrypted data.

Assuming the file was encrypted with a password (or key/IV pair) that you have, you will have to try every every method:

ciphers=$(openssl enc -h 2>&1 | nawk '/^Cipher/ {n++; next}; (n) {print}')
password=xyzzy

for cc in $ciphers; do
    openssl enc -d $cc -pass pass:$password \
        -in myfile.txt.enc -out outfile$cc.txt  2> /dev/null
    rc=$?
    # check for non-zero exit, or output file size not > zero bytes
    if [ $rc -ne 0 -o ! -s outfile$cc.txt ]; then
        echo "Failed with $cc"
    else
        echo "Possible success with $cc"
    fi
done

(There are some duplicate ciphers due to name aliases, e.g .aes-128 = aes-128-cbc.)

Now you'll see the next problem, with many algorithms you can decrypt ciphertext with a bad password and not know if the algorithm and/or password were correct.

There are a number of methods to determine if a password was correct and a decryption was successful (e.g. via checksum, integrity (e.g. with HMAC), padding (e.g. with PKCS#5) or other expected structure, or known "left over" state), though sometimes not being able to tell is in fact a feature.


Secure file sharing, instead of attaching files to emails?

There are many products that will detect outbound emails with attachments; simply block all outbound emails with attachments, configure the block to respond to the sender with a message informing them that they must deposit the file and share the link.


Does OWASP's top 10 list cover the majority of potential web application vulnerabilities?

From OWASP:

  "It represents a broad consensus about the most critical security
  risks to web applications."

So, yes, by definition, the goal of the Top 10 is to describe the "majority of potential web vulnerabilities".

But your next step is not logically supported by that fact.

  performing an "OWASP Top 10" scan provides enough coverage to consider
  it an "in-depth" scan

I can list the top ten most common human diseases, but that does not mean that any given diagnostic scan for those diseases is comprehensive, complete, or accurate.

An "OWASP Top 10 scan" cannot possibly be definitive for all possible instances of those vulnerabilities, and in fact, some items on the Top 10 list cannot be scanned for.

So, no, an "OWASP Top 10 scan" cannot be described as an "in-depth scan". Depth is defined by how the scan is performed, not by the broad categories of vulnerabilities it is inspired to look for.

The OWASP Top 10 is descriptive (backwards-looking), not prescriptive (forwards-looking). From examined web apps, the ten biggest problems found are those ten. That does not mean that there are only ten possible vulnerabilities classifications.

And that does not mean that knowing these ten exist makes it possible to find them in any given web app. When breaches occur, it may be possible to trace things back to these likely vulnerabilities, but that's easier when you have the breach to start from. It gets significantly more complex if you are starting from a well-running app.

However, if you can find them in the web app from a scan or some other automated or simple process, then that's an indication of a significant weakness in the web app since attackers will also use these methods.

An in-depth analysis (not scan) of a web app includes many different approaches and techniques to quickly provide coverage of possible vulnerabilities before release. But remember that attackers have all the time in the world to look for the one thing you couldn't find in time.


How DHCP client can determine that 802.1x Port based authentication has been completed and its time to trigger DHCP discover

This can be done in two ways. 1st, if the DHCP client is in application control that has responsibility to perform authentication then DHCP DISCOVER can be sent once authentication has been completed and client knows that data access has been allowed.

If a DHCP client is out of application control i.e. Linux self DHCP client then DHCP manages it internally. When client transmits the DHCP discover message and switch doesn't replies client will keep retrying the message and the switch can use this message to trigger authentication.


Yes, this is one possible approach to defending against CSRF. It's called the double submit cookie pattern.

The synchronizer token pattern - the second token isn't stored in a cookie but server-side in the session - is a bit more common in practice though.


Is a wireless receiver a security weak point?

It's wireless, so you might be able to sniff it if it doesn't use encryption by monitoring the connection.

However since it probably closed source you will not know if the program driver supplied is safe. Does it use RSA or AES encryption ? Even if they use these protocols, might they be extracted from either remote or receiver ?

Can someone else send signals with their remote (maybe by analyzing their remote and apply some homebrew that hasn't been published yet) ?

Wireless devices are per definition often less secure than their wired equivalents. If you want complete security, don't use it.


TLS requires a reliable transport. On the internet, this leaves only TCP, as UDP does not offer reliability.

TLS does require a reliable transport because (in compliance with the layered architecture of the ISO/OSI reference model) it does not handle transport errors, lost packets or other disturbances that may occur with IP.

TLS is designed to offer a secure channel on top of a reliable transport and it does this quite well. DTLS does (I assume) the necessary error handling within the protocol.

If TLS was to be performed over UDP, connections and handshakes could fail just because a packet got lost in transit and no one noticed.

Mitigation of such problems is (according to the ISO/OSI reference model) the designated task of a reliable transport. Any reliable transport works theoretically, yet for all practical purposes of IP networks, this usually implies TCP.


Log all crypto keys used for outgoing SSL / TLS connections on Linux server

The NSS SSL Keylog file is a non-obtrusive way to extract SSL session keys from an application using the NSS library for SSL/TLS, but there is no standard way to do the same in all applications. (A generic approach would involve a man in the middle attack, but this is not really non-obtrusive.)

The idea of the extracting session keys directly from the application is more widely applicable though. libssl.so suggests that OpenSSL is in use on a (likely) Linux platform. You can either use use LD_PRELOAD to interpose the OpenSSL library (may not work in all cases) or attach a debugger with appropriate breakpoints. Both approaches are documented and explored further in Extract pre-master keys from an OpenSSL application.

As an additional tip for troubleshooting, while Wireshark 1.12 is able to decrypt the TLS application data (and Follow SSL stream can be used to look at the communication), it does not dissect the SMTP traffic which occurs after a STARTTLS handshake (SMTPS is unaffected). In Wireshark 2.0 (tentative release date in November 2015, pre-release versions are available) the SMTP protocol is correctly recognized after STARTTLS.


Buffer Overflow PoC code \x11(setup sound

According to https://vuldb.com/?id.29211 there is a memory corruption in the function setup of request.c. While I'm not familiar with the full details of the vulnerability, the exploit connects to a socket so it is presumably part of the networking protocol. The \x11setup sound string is likely the syntax that causes the server to invoke the setup function in request.c if you cannot cause the code execution to enter the vulnerable function then you cannot trigger the vulnerability.

You usually see a semblance of correct syntax in network protocol and file based exploits for this reason. This exploit for example, contains several FTP syntax commands to reach the vulnerable function: https://github.com/wireghoul/sploit-dev/blob/master/freeFTPD-bof.pl


AviD was on the right track with the idea of taking IP frag attack concepts for evading network level IDS and applying it to layer 7 http data.  If you wanted to split up say an SQLi payload so that it may evade input filters and still work against the back-end system, the attack technique is called "HTTP Parameter Pollution (HPP)".  HPP is an attack where the user sends a request where multiple parameters have the same name.  In these cases, there is a wide level of variance in how the apps will respond.  Will they take the first payload?  The last?  In the case of ASP/ASP.NET sites, they actually will concatenate all payloads with the same name. This allows for a "fragmentation" type of attack.  See my previous blog post on the topic -
http://tacticalwebappsec.blogspot.com/2009/05/http-parameter-pollution.html

and here

http://tacticalwebappsec.blogspot.com/search?q=parameter+pollution

Also of note - the current version of the OWASP ModSecurity Core Rule Set (CRS) has an experimental ruleset for HPP which will mimic ASP and concatenate any params with the same names into custom TX variables for inspection by later rules -

http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/experimental_rules/modsecurity_crs_40_http_parameter_pollution.conf

Cheers,
Ryan


Is this PHP code vulnerable SQL injection?

Removing comments helps against some injections, but by all means not all.

In this case you can still zero any field by setting $vote to construct a logical sequence out of what was an assignment:

 variable   :          vote`=1 + `vote
 query      : ... SET `vote`=1 + `vote`=`vote`=1 + `vote`+1;

This will alternate vote between 0, if it is nonzero, and 1, if it is zero.

But since you can specify a field more than once in the same update, and all the updates will be run, you can also do:

 variable   :          vote`=1, `vote`=X+`vote
 query      : ... SET `vote`=1, `vote`=X+`vote`=`vote`=1, `vote`=X+`vote`+1;

which sets the vote to 1, then to 0, then to 0+X+1, whatever X (except X=0 where it will set the vote to 2).


Provided a server is involved in the authentication process, yes, it is possible to sniff the login credentials.


How should we announce vulnerabilities in our application?

I recommend reading the CVE FAQ.  In short the CVE system is created to share knowledge of vulnerabilities in software, keep track of their severity and reduce the duplication of effort.   The fundamental purpose of the CVE system is to notify users that they are in  danger,  and to update immediately.

It is appropriate to obtain a CVE for any publicly disclosed vulnerability that could endanger users.  A bug found internally though QA, is probably not being publicly exploited, and therefore a CVE would probably not help.

Consider offering a mailing-list to your users to inform them of security related updates.


Is MIT Kerberos supposed to ask for a password when authenticating to SSH?

The simplest answer is probably not.

From looking at your current setup you are trying to use GSSAPIAuthentication. If your kerberos environment is properly set up then it should not be required to enter a password again after initially requesting your TGT. with this properly received it is only the TGT that is required to request the service ticket.

Some things to look out for are the following:

Things are simpler if you follow the convention of keeping your realm name in UPPERCASE.
Make sure all SPNs in your KDC match the FQDNs of the hosts you are authenticating to.
Make sure all hosts are actually aware of their FQDN. This can be achieved by editing /etc/hostname, /etc/hosts may also be useful.
It also looks like you are receiving brute force attempts against your ssh daemon as the user root, this can be helped by installing something like fail2ban. Failing this, you can run an instance of sshd in the foreground, on a non standard port, with extra debugging output using this command sudo /usr/sbin/sshd -p 9001 -D -dd. This will give you cleaner logs.


There are lots of ways to run the downloaded code:

Write a file and then exec it as you note
The payload might be written in a language that the loader is an interpreter for.
The loader could exec a shell or other scripting executable (python, ruby) and pipe the payload to it as a script.
The loader could mmap executable memory, load the payload into it, assign a function pointer, and call it.

I'm sure there are more approaches, but I suspect that covers the major categories (write and exec, interpret it, give it to someone else to interpret, or run it directly). There may be some ways to trick the system into exec'ing an ELF executable that isn't written to the file system (maybe through a named pipe), but nothing comes immediately to mind.

EDIT: See fexecve(). This should let you create a pipe, fork, and then fexecve to read the executable from the parent's pipe without writing a file.


Detecting(and locating) rogue DHCP server on a local area network

You can use an nmap script for locating a server that will send DHCPOFFER (so long as it's in your broadcast domain):

nmap --script broadcast-dhcp-discover

This will give DNS domain name, your IP, who offered it, lease info..all of the fun stuff.

You can also include a list of hosts that have anything to do with port 67:

nmap --script broadcast-dhcp-discover -p67 [your network CIDR]


I need help finding a list or a reference of DLL's for discovering hijacked programs

If you are positive the box is infected by malware (but do not necessarily know which one), first thing I would do is image the HDD using a tool like clonezilla. If he has not rebooted since he first observed the malicious behavior, you could also try to take a memory snapshot you could later analyze with volatility.

After that I'd reinstall the machine and do offline analysis of the image at home.


Should I know my users passwords so I can check they can logon?

You can replace the users passwordhash with a hash you DO know the password for, save the users passwordhash so you can place it back later and then login to the system with the users credentials.


What's the use of adding a challenge to a one time password algorithm?

I think this is to ensure that the response entered into the website is a fresh(ish) one. If the one time password was generated directly then it could be used at any point in the future, the server has no way of checking when it was generated. By providing the challenge to the card it means that the response generated can only be used for the transaction with the matching challenge.

Here's an example of an attack that takes advantage of the fact that a challenge isn't used for all online transaction or logging into your bank account:

  A similar attack could be performed with CAP. The customer, using a
  tampered Chip & PIN terminal, would insert their card and enter
  their PIN as usual. The terminal would then generate the necessary CAP
  responses, and optionally also carry out the legitimate transaction.
  Shortly after, the customer would receive a personalised phone call
  or email, stating that a suspicious transaction had been noticed
  (stating the shop name they just used), asking for their online
  banking credentials. Since Barclays only uses identify and sign mode,
  there is no server-provided freshness or a timestamp, so the
  previously collected responses can be used, provided the customer had
  not logged into online banking in the meantime. With NatWest, which
  uses respond, there is a server-provided nonce, so the fraudulent
  transaction has to be in near real-time, and account credentials would
  need to be collected before the CAP responses were generated. The
  banks could resist this problem by offering separate CAP-only cards,
  but NatWest refused to do so for one of us.

It's taken from Optimised to Fail: Card Readers for Online Banking by Ross Anderson, a paper that talks about the CAP protocol and its various vulnerabilities. His group have many other interesting papers as does their site on Chip and PIN.


How to securely store accesstoken in android

Can this be achieved with Keystore?

I don't think that fits your use case. Keystore is designed to store cryptographic keys that will be used for encryption, decryption and signing. The idea is that these keys will be out of reach of the application using them, so basically, if you need something signed or encrypted, you call a system function that has access to the keya, but you can't get the keys themselves. This protects them from compromised applications. This doesn't work for you, since you need access to the access token itself.

If you  used Keystore to encrypt and decrypt the access token, this would protect the access token from other processes (or from being extracted by forensic software from the filesystem - but see about access token expiry further down...). So that would definitely enhance security. But if your app was compromised, an attacker would still get access to the decrypted access token.

  Is there a more secure way than using localstorage?

I'd say that if you want to protect against someone with root access and/or a compromised application, then no. You can't protect a secret from root, no matter where you store it on the device, except maybe in trusted computing platform hardware (this isn't exactly true - linux systems support security capabilities which root has by default, but may be denied by the kernel if so configured - but I think that's not very relevant for this discussion)

The problem with protecting from root is that root has access to everything your app can access, so even if you encrypt your access token, root would have access to the encryption key and could decrypt it. The same holds when your application is compromised.

One way to add a bit of security might be to have a service which is housed outside the device do an additonal layer of encryption and decryption of the access token based on a revokable key, so if the device was lost, you could revoke the associated key and then the encrypted access token on the device would be useless. But for this solution, you'd need to have two layers of encryption, one on the device (otherwise, you'd open up a new vulnerability by sending plaintext access tokens over the network to another service)  and one on the service.

However, this strikes me as a ludicrous amount of work to protect an access token (it might make a bit more sense for a long-lived renewal token). Access tokens are generally short-lived and if you deleted an access token as soon as you no longer needed it, that would also increase security.

Storing the access token somewhere other than localstorage might, however, be more secure than localstorage because localstorage is accessible using javascript, so if your webview was infected with malicious javascript, it could steal the access token. But since your own code in the webview probably needs access to it, you're out of luck.

BTW: I'm assuming you're talking about a oauth access token. oath was originally designed to solve authorization for server-side applications which are used by user agents (browsers). oauth 2 then extended this to include authorization and authentication flows for other scenarios, such as for javascript apps running in the browser or apps sitting on devices controlled by the users themselves, but there are a few people (the original editor of the oauth 2 spec among them) who complain that oauth 2 support for these alternative scenarios isn't very good/secure.


What are the risks of protecting an API with one key only (without secret)?

First: you cannot be sure that the API key is private and will remain private.

As soon as the device/product/application is on the real world, it can and will be broken. Don't rely on it.

And as soon as the key leaks, nothing will stop anybody to simply start sending requests, and you can't tell who is sending, or how to filter or block fraudulent requests.

Creating a secret is not hard, and you must do it. It will save you a lot of trouble along the way.

If a hacker breaks the application and gets the key and secret, you revoke access to that secret and he loses access to the API. All your other uses continue using the API without problem. Without the secret, you must create another key, and all your clients lose access.


In response to only (2) above: if a private cloud is actually allocating computing resources on demand to users with certain passwords/keys (like AWS) -- it is then over and beyond plain virtualization in the enterprise and risks additional to simple virtualization need to be mitigated.

If private cloud resources are allocated/deallocated and managed by the DC ops team, then it is no different to plain virtualization from a security perspective.

A couple of mitigation steps we took at a retailer that implemented something in between the two scenarios described above:

Managing provisioning passwords and/or keys, with information to users how significant they were and how to protect them.  This is especially important for pivate clouds, which are generally in a trustful internal environment.
Immediate emails on allocation/de-allocation of resources, and frequent chargeback reports to multiple stakeholders in departments allocating resources.


AES Keys Storage for encrypting hashes of SAM file in Windows 10

The AES Key to decrypt the Double Encrypted Hash is derived from the “SysKey”, which is in itself also AES encrypted.


What are the ports used by Online Email Accounts such as Yahoo Mail, Gmail, etc.?

Let us break this down into three parts:

Between domains, the protocol is SMTP, which is essentially a relayed protocol.  If SSL/TLS is not being used, a sniffer will detect anything.  If SSL/TLS is being used, a packet sniffer will be able to know the from and to IP addresses, and any relay on the way would have to decrypt and then re-encrypt the email.
If using POP/IMAP/SMTP from a thick client (e.g. Outlook) to any one of these services, the port numbers vary but there are well-known ones.
If using the Web interface of these services, then the ports are 80 (HTTP) and/or 443 (HTTPS) from your user agent (browser) to the originating domain - (Google or Yahoo).  There, the packets are de-crypted to clear-text and then optionally re-encrypted if the target domain or a relay supports SSL/TLS over SMTP.  After that, the process reverses itself: If your target domain's user is also using a browser, then the reverse will happen and clear-text email stored on the target domain's mail server will be encrypted to HTTPS sent over client ports (random ports) to the end user.

In short,

if not using SSL/TLS, everything is visible.
if using SSL/TLS, everything is visible to the relays but not in transit.
port numbers may vary.


Start by reading the answers to these questions:

How to disclose a security vulnerability in an ethical fashion?
How should I escalate ...

Start by trying again, possibly with a different email address (unless you received a personal confirmation, you can't be sure someone actually read your email).

If that doesn't work, I would say it depends:

If it's a big, famous site with high visibility, there are sites to
publish this to. (http://isc.sans.edu/diary.html?storyid=8701 lists
some, but I'm not completely comfortable with that.)
If it's a
smaller unknown site - there's no reason to publicize the
vulnerability, it will just draw attackers that otherwise would not
even know or bother with them.

There's really not much else to do - you've already performed your civic duty.


Are my DNS requests encrypted when I use VPN and DNS of Google or others?

I'm assuming the typical setup that your VPN setup forwards all non-local traffic encrypted to the the VPN exit, i.e. all traffic to other systems in your local network will not be encrypted. I'm also assuming that the VPN does not come with its own DNS since you specifically ask about a DNS you've configured yourself. In this case the answer depends on where the DNS is configured and where the entry to the VPN is.
If your computer is the entry point of the VPN but you have DNS configured to be resolved by your router, then the DNS lookups will bypass the VPN, no matter if the DNS on the router forwards to your ISP's DNS server or to something else.
If the entry point of the VPN is your computer and you have your ISPs DNS configured on your computer, then the DNS will pass through the VPN and thus be encrypted. Note that even DNS lookups to your ISP will pass through the VPN unless you are directly connected (without cable modem, DSL router or similar) to the ISP, i.e. as long as the ISP's DNS is not in your local network.
If the entry point of the VPN is your router (i.e. router with VPN functionality) then all DNS lookups will pass through the VPN (i.e. encrypted) as long as the configured DNS server is not in the ISP's local network.


Is fail2ban an intrusion prevention system?

Before categorising anything, it's important to understand the taxonomy first. That way you don't get bogged down in words that could have different meanings.

An IPS or an IDS is defined as a network-level detection control. A Host-Based IPS (HIPS) will also look at internal data but primarily looks at the network.

Given this differentiation, no, fail2ban is not a HIDS because it does not inspect the network (it looks at logs).

If you try to expand the taxonomy beyond its intent, then any host-based control could be considered a HIDS, like anti-virus or an OS-level account lockout on too many failed login attempts.


Is server startup time sensitive information?

Yes, this could have value as a source of info.

If the attacker is looking to see if a DoS is working, then the server uptime can provide data about success. Alternatively, knowing that a server has been up for a very long time can indicate that resources might be starved, or it is unpatched.

It could also be used to get a sense about the infrastructure's response to load. If you are in a DevOps scenario, where you generate new servers, one could start to map out the unique servers and make some estimates about how many servers you might spawn (if a small pool) or at what load you start to spawn new servers.

Uptime could also be used to uniquely identify one server in your cluster.

The real question is: how much value is this to an attacker? That will depend on your specific environment.

I might push back on the term "sensitive info", because I do not think it is. I would rather use your other expression "useful information" because it might not have intrinsic value by itself, but can help provide secondary information that an attacker could certainly take advantage of while pursuing other goals.


If I understood well your question's title, and if you are looking for opensource stuff:

  I know, FireFox and Chromium are Open-Source and would be the base for
  such Honey-Browser.

then you can use, for instance, Thug which is a browser emulator written in Python automatically interacts with the malicious website to check its exploits.

There are also other Thug equivalent tools.

Note that the attacks upon browsers are mainly done using malicious JavaScript code performing especially drive-by download attacks. One of the solutions I implemented myself to detect compromised websites intended to target clients/visitors is based on a honeypot that uses several virtual machines on which different operating systems and browsers are running -without antivirus intalled- and a program that checks the health of the operating systems and browsers during and after the automatic navigation of all the pages of a given URL.


Identify an attacker's web vulnerability scanner by IP request rate

Configure your vulnerability scanner to wait between requests or ask your customer to whitelist your IP knowing the fact that you have probed that this countermeasure is being effective.


Best way for a hacker to hide a file on Linux?

If I have root on a system and really want to hide a file, the obvious answer is a rootkit, which can hide any files I want from almost all detection, by hooking filesystem reads etc. Rootkits are incredibly hard to find in a normal working environment, as you can't trust anything the OS reports. If you have Tripwire on a system, working correctly and monitoring the entire filesystem, the installation of a rootkit should be detected - however if an attacker can get root and has access to the Tripwire systems, then all bets are off.

What is much more likely in practice, however, is for files to be hidden in the depths of the filesystem, perhaps under . directories so they don't show to a normal ls, or perhaps as innocuously named files. The good thing is that more linux admins seem to know what files should exist than windows admins, probably more down to the fact that windows is managed typically through a gui, however with greater usage of Powershell this is changing.

Writing files to an unused portion of a disk can work, however in an enterprise environment you tend to find disks fully utilised, so an attacker would first need to either alter a partition or find some way to hide the use of a section of existing filesystem. It happens, but not as often as you may think.

Steganography is not used very much. Malicious executables are found in innocuous looking files, but usually as a vector, not in storage.

In summary, from a defenders perspective, protect root, patch regularly and use Tripwire or an equivalent.


Is it possible that a single handshake can have 2 TLS versions included?

Due to backwards compatibility concerns, TLS uses a fake TLS version number in the record layer.
struct {
          ContentType type;
          ProtocolVersion legacy_record_version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

legacy_record_version:  MUST be set to 0x0303 for all records
      generated by a TLS 1.3 implementation other than an initial
      ClientHello (i.e., one not generated after a HelloRetryRequest),
      where it MAY also be 0x0301 for compatibility purposes.  This
      field is deprecated and MUST be ignored for all purposes.
      Previous versions of TLS would use other values in this field
      under some circumstances.

(from TLS1.3 RFC)
0x0300 is SSLv3, 0x0301 is TLS1.0, 0x0302 is TLS1.1, 0x0303 is TLS1.2.
Your tool displays this field and confuses you. Disregard this information, it is not useful. Replace or fix the tool, or just live with the fact that using TLS requires knowing about the backwards compatibility baggage.
In your transcript, it looks like the handshake succeeds, and then a syscall error happens. But that is not a logical error (like negotiation error caused by no common version or cipher suite, bad cryptographic authentication, etc). Instead that is a programming error, an error with the OS (probably socket) API. Help with programming errors is offered on stackoverflow.


If you just want to get your honeypot machine compromised and part of a botnet, you will need to be running vulnerable services on the machine.  The vulnerable services you choose will have to match the ports that you have forwarded to the honeypot machine and will also have to match the services that worms are actively trying to exploit.

For a Windows XP machine, forwarding ports 137, 138, 139 and 445 should get you plenty of attack traffic.  These ports are for NetBIOS and Samba and they all receive a constant stream of traffic from the internet.

Forwarding port 80 will only be useful if you are running a web server on the honeypot machine.  You can go in two directions with a web server; either run an old version of the HTTP daemon itself that has known vulnerabilities or run a current version and then run a vulnerable web application such as an older version of Wordpress or phpMyAdmin on it.

You can just try running services and hoping that they are vulnerable and that worms are trying to exploit them but it might be more effective to look up the services that specific worms target and run those.

The other direction to solve this problem from is to enable logging on your ingress point and see what traffic is hitting you.  I suspect you will see a lot of traffic on the ports I mentioned above but you will probably see traffic on other ports as well.  Find out what the ports are used for an run that service on your machine.

There are a few things I would add to this regarding honeypots:

The purpose of a honeypot is to study what the attacker or worm does once it compromises a host.  You will want to set up extensive monitoring and logging on the box itself so that you actually gain some useful information out of the exercise.  It's also important that you know when you have been compromised.  Most honeypots are run inside virtual machines in order to give you an easy way to compare the current state of the machine to a known good copy.  It is not adequate to do this from within the honeypot because rootkits can modify the very tools you are using to do the comparison.

You will want to be monitoring all traffic to and from the honeypot machine.  By this, I mean full packet captures.  The normal way to do this is with a spanning port on your switch but it can probably be done in the hypervisor of the VM if your switch doesn't have that capability.  You would normally not do it within the honeypot.

You said that you are aware of the dangers of running your honeypot inside your home network.  I presume that means you're also aware of the precautions you will have to take before putting it online.  Specifically, configuring your network and firewall so that the honeypot machine can't contact any of the rest of your local network.  It's also good practice to be careful about which outbound connections you allow it to initiate to the internet.  The first thing it will often try to do is to download a rootkit and the worker programs which you are probably interested in, however the next thing is often to start attacking more targets, and this is not something you would normally want to allow.

There also exist specific tools for creating honeypots.  These tools include entire hypervisor and VM stacks that enable all the things I have mentioned above.  On the same site you can find tools for logging, monitoring and analysing and also a load of information on how to run a honeypot and who you're likely to see attacking it.


Two certificates with HSTS on different ports?

Yes.  It works fine.  Just add listen <port> ssl and the certificates to each server stanza:

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          444  ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com2.crt;
    ...
}

HSTS shouldn't cause problems but certificate pinning might.


It sounds like you are wanting to run a bare metal hypervisor as a desktop. This is only recently been supported on platforms like vSphere and Xen due to PCI/VGA Passthrough. If you are looking for any real performance, you are going to be slightly disappointed with this setup.

What I generally suggest is to install the operating system, install the applications you know are safe and stable, configure the machine to your liking, and then take an image. Windows 7+ makes this process almost stupid easy, to the point where you can restore a system to its previous state in less than an hour. This is exactly what you would be doing with a VM, except it would not be virtualized.

To answer your question, it is a viable security measure. I don't know how practical it is though. I've done this exact thing before, and usability as a desktop was not optimal.


iPhone full disk encryption and theft protection?

iOS4 has introduced (a somewhat secure) Full Disk encryption for the iPhone. The encryption itself is done by hardware and uses  AES-256 to encrypt your data.

An iPhone has two partitions:

System data
User data

The user data part gets encrypted with an AES-256 if enabled. The key for this is a passcode you must enter every time you want to unlock your phone. This ensures the data partition cannot be decrypted in an easy way. So if your phone gets stolen and the attacker doesn't have the passcode, he can't access your personal data.

The problem here is that's what Apple is telling us. There is a VERY BIG BUT that's following now.

Security researchers found out that the all of this security can be bypassed by a device that speaks the Apple control protocol.
Also there seems to be a problem that all of this can be bypassed if you are able to Jailbreak the phone. The problem with this option is that the iPhone itself needs to be paired prior to a computer prior to be able to do the Jailbreak (if there is a way to bypass this please leave a comment). When the phone is Jailbroken an attacker can install an SSH daemon and just take a raw copy of all your data...unencrypted now.

If the above is fixed by Apple, you would have a reasonble secure device. So to protect your data you will need some extra apps that allow you to remotely whipe your iPhone and secure your emails safely.

Now besides all that is also nice to note that Apple has provided a complete Security API for developers. They can use it to produce Apps that can securely encrypt just about anything. Unfortunately, there are few Apps using it.

Email clients:

GOOD for enterprise
Integrated Email client (apparently should encrypt all emails too, but I could be wrong if it relies on the same hardware security)

Wiping:

When using Exchange push email you can do this through the exchange client (for your email)
using iCloud, it has a feature to locate your iPhone and wipe it.

This are just some features and there are probably a lot more, so please feel free to share the knowledge and correct me if I'm wrong.


Is a HMAC-ed password is more secure than a bcrypt-ed or scrypt-ed password?

In order to give you a proper idea of the problems and subtleties of computing password hashes, as well as why HMAC isn't suitable for this problem, I'll provide a much broader answer than is really necessary to directly answer the question.

A HMAC hash algorithm is, essentially, just a keyed version of a normal hash algorithm. It is usually used to verify integrity and authenticity. The usual notation of this is H(m,k) = h, where H is the HMAC hash algorithm, m is the message, k is the key, and h is the resulting hash. The idea is that two parties that share a secret k can verify that the other person is the author of m. Furthermore, an attacker cannot forge a message hash without knowing k.

This is done as follows:

Alice and Bob both know a shared secret key k.
Alice writes a message m, and computes the HMAC hash of it using k, i.e. H(m,k) = h.
Alice sends the message m and hash h to Bob.
Bob computes H(m,k) and compares it to the hash h that Alice sent. If the hashes match, he knows that Alice sent the message, and that it was not altered after she hashed it.

Now that you understand what HMAC is, let's move onto what you really want to do - store passwords in a database.

Many years ago, it was standard practice to store passwords in plaintext in databases. This was a bad idea because, when the database was compromised, the attacker got all the passwords. To combat this, we started hashing passwords in the database using one-way cryptographic hash algorithms. MD5 became popular, but weaknesses (collisions, partial preimage, etc) discovered in it mean it's no longer recommended. A lot of people moved onto SHA1, which is more secure.

The problem with this approach is that it's possible to construct a huge table of hashes and their corresponding plaintexts. These are called rainbow tables. They work on the concept that it is more efficient to compute a huge list of hashes for all possible passwords (within a certain set) and then store it, so it can be quickly queried later on. So, instead of brute-forcing individual hashes, it became possible to just query the database for a hash and have its plaintext returned immediately.

In order to fix this, security nerds invented salts. Salts are large unique random values appended to passwords before they are hashed. This salt is stored with the hash, so that it can be computed again later. So, we compute H(m+s) = h, then store h and s in the database. This provides significant protection against rainbow tables because it essentially requires a separate rainbow table to be generated for each salt.

So, the bad guys switched back to dictionary attacks and brute-force cracking. With the advent of GPU computing, it became possible to compute billions of hashes per second on a moderately powerful graphics card. In fact, people have built computers that can compute nearly 50 billion MD5 hashes per second - pretty impressive / scary. The reason GPUs are capable of this is that they're designed to do huge numbers of parallel scalar operations. Scalar operations are math and logic operations that do not involve branches - i.e. they don't need to do much/any "if x then do y". Cryptographic hash algorithms tend to fit into this model.

In order to make this difficult, we have to make the hash operation slow enough to make brute forcing infeasible. Normal hash algorithms (e.g. SHA1) are designed to be fast, which makes them unsuitable for this purpose. HMAC adds very little overhead and no extra security margin, so it too isn't much use here.

Creating a slow cryptographic hash algorithm is easier said than done - it's very hard to come up with one that is slow, irreducible (i.e. cannot be optimised beyond its current state) and secure. There are three popular hash functions that can do this: PBKDF2, bcrypt, and scrypt. These are known as adaptive key derivation functions, because they accept a work factor value along with the plaintext and salt. The work factor alters the amount of time it takes to compute the hash, and is designed to safeguard against future hardware improvements.

So, for an adaptive key derivation algorithm H, we compute H(m,s,w) = h, where m is the message (password), s is the salt, and w is the work factor. The resulting h usually contains s and w, so that a verification function can later compute the same hash using the same parameters. The work factor generally controls the number of iterations performed of an internal cryptographic primitive. The goal is to make the computation take long enough to make cracking infeasible, but not to exceed the resources that we have.

In order to provide more security against dedicated hardware-based cracking, scrypt ensures that the hash computation is both CPU-hard and memory-hard, i.e. it requires significant CPU and memory resources in order to produce the hash value. This is important, because FPGAs usually have access to very little immediate memory.

Now, the obvious question arises: if I set up my site to use bcrypt, won't that mean my server has to compute CPU-intensive hashes all the time? Well, if you run them on your server, then yes, that's something to take into consideration. A better solution is to have the client compute the hash, then send it to the server over SSL. The server can then compare it to the value in the database. This ensures that the password hash cannot be easily cracked if it is stolen (e.g. through a database compromise), and that your server isn't overwhelmed by the overhead of password hash computation. For websites, you can use jsBcrypt. Update: This method has been pointed out as flawed by a commenter below. Don't use it.

Hopefully this gives you a good overview of the situation, and why HMAC isn't suitable for this kind of use.


Storing Private Keys Generated on Server with specific User's Password Securely

I am not sure of what you are trying to achieve here. If you are trying to secure user data, so that only the receiver of the message has access to it, then a solution would be:

Generate the certificate on the client, using the applet and protect the private key using a password (the user password or another password)
Send the public key to the server so that it is available when someone wants to send an encrypted message.
The private key should not leave the computer of the client. The obvious problem here is that if the user uses another computer to access your application he would need to copy the certificate there. You can solve this problem by using smartcards or USB tokens and store the certificates there. In this way, you would only need the token's password to access the private key.

If you also have some sort of admin functionality and you have an user that should be able to decrypt everything, then things get a little bit more complicated. You may have an admin certificate and after the applet generates the keypair, encrypt it using the admin's public key and send it to the server, where  you should store it in an encrypted form.

At least the admin should have an USB token with his certificate, so that even if an attacker gains access to your server, he would not have access to any of the private keys that could decrypt messages.


Can a polymorphic/metamorphic worm use a mutex?

Short answer: no.

The point of polymorphic malware is to have no identifiable pattern. If you use a named mutex, you need to know the name of the mutex on both processes. To know the name of the mutex, there must be a pattern to it. If there's a pattern to it, the AV can use that pattern to detect the malware.


Does Google record search / source IP [/ user] pairs?

Yes, maybe, no...  Only some Google' employee can answer the question, even then they might give you false information.

A lot of sites and users out there are taking the assumption that Google and other major sites, are taking as much record as possible. For example Eli Pariser talk on filtered bubble suggested that Google is/could take track from 57 signal including web browser being used and where the computer is located.

"Usually your searches are saved along with the date and time of the search, some information about your computer (e.g. your IP address, User agent and often a unique identifier stored in a browser cookie), and if you are logged in, your account information (e.g. name and email address). " DuckDuckGo Privacy

Even if you are not logged in, Google can/could use several methods to identify you over time, again only some Google employees or someone who has solid proof can verify this.

How to create a basic extra layer of privacy/anonymity when dealing with Google?

Simplest solution:

Stop using Google, but I wouldn't recommend that maybe balance queries between two search engines like: DuckDuckGo which in short it is a beautiful, customizable search engine, but I have had better luck finding things with Google. DuckDuckGo has worked for me when doing simple queries (such as 'New York Doctors).

Still Want To Use Google?:

Customize this as fitted to your needs:

Browser: Firefox Why Firefox? As of Jan 2011 W3C reports 37.1 %  of users use Firefox, followed by Chrome 35.3 %. Making it the most used browser, the less unique the better. I recommend Firefox if you are trying to prevent Google to record any relevant information that might identify you.

Settings: Edit->Preference->Privacy:

[check]Tell Websites I don't want to be tracked.
[select]Use Custom Settings.
[unchecked all except the following:]
[check]accept cookies from site &[select] Keep until I close browser
[check]clear history when firefox closes

Proxy: If you have security expertise you might have heard of Tor or have used it before. Wouldn't recommend to always use it, except when you don't want certain personal information to be record.

Advertisement: Adblock

Track Request Blocker: Disconnect

HTTPS: HTTPS Everywhere

Once more, I am not able to answer your exact answer as I am not a Google employee neither do I have evidence to say Google is recording your searches. But I have given you some ideas on how you can create an extra layer when dealing with delicate/personal queries you wouldn't want to get recorded.


What is claimed here about a vulnerability in the target of a "really common shell"?

They're claiming that they found a webshell installed on a bitcoin exchange site.  So the vulnerability is that someone has already compromised the exchange's server and left the webshell sitting ready to take commands from anybody... and that as a "really common shell", lots of people would know how to find it and use it.
Not enough information to tell which common shell it is, however.


What is the value of vendor specific security certs vs. general ones?

Do mind that within security there are different segments. You have:

security analysts
penetration testers
forensics
network security
...

When applying for a job it is important to look at the job description. If they are looking for security specialists in a networking environment then obviously a Juniper/Cisco security certificate will be plus, whereas a MS security cert will be of less value.

If you are working as a penetration tester then the OSCP/OSCE would be more appropriate.

It really depends on the job.

Some certificates like CCS or OSCE show that you are capable/willing to learn very difficult things. Which will also be considered.


What is stored on a banking card and how is it protected?

“Chip and PIN” banking cards have a chip, as the name indicates. The chip performs cryptographic operations and stores secret keys. The chip isn't just storage, it's a processor and the storage is not directly accessible from the outside.

The chip is physically protected against duplication — it's embedded in a protective layer and designed to self-destruct if someone tries to peel off the protection. There are software and hardware countermeasures to protect against side channel attacks such as electromagnetic emissions measurements. For more information about protection against physical attacks, see

Smartcard security on Wikipedia
chapter 16 of Ross Anderson's book Security Engineering (a recommended read in any case)
EMV Security? How is it possible that it's secure?
What physical, electronic, and software characteristics are important in a smart card?

The card stores the card number and other identifying information. It stores secret keys that it uses to communicate with the bank. It also stores the card number and a hash of the PIN. It also stores a PIN attempt counter: after three successive incorrect attempts, the card refuses to validate PINs anymore.

Smartcards used in corporate settings use the same basic technology, but banking cards are usually a grade above, incorporating the latest countermeasure technology when corporate smartcards often have previous-generation security (but sometimes higher performance, if they need to do asymmetric cryptography to sign messages). Smartcards used in access control are often several grades lower in terms of security (“cost-conscious”).


Client side encryption - only web browser available

JavaScript cryptography is not a good idea

JavaScript cryptography is not bad per se, it's just ineffective against most commonly considered threats.

If you consider a man-in-the-middle (MITM) to be a threat then SSL/TLS is a much more effective control as otherwise the attacker could substitute the JavaScript for a version which doesn't use encryption.

If you consider malicious software on the client side to be a threat then it could presumably modify the JavaScript any way it likes and your encryption would be useless.

If you consider the server side to be a threat (eg. the client wants the server to store something but not see the content) then it may be effective, but the client needs some other way of ensuring the JavaScript hasn't been tampered with (which isn't an easy problem to solve) and the client needs to manage the key themselves.

In the use case you've described it doesn't sound like client side encryption will really add any additional security. Either way you have to deal with the issue of communicating the key, which will probably depend on the integrity of SSL/TLS regardless. Either the client will have to send the key to the server or the other way around, and even if you use public key encryption to address this you'll still have the issue of ensuring that the public key sent to the client is authentic. You'll most likely just end up reimplementing a typical public-key infrastructure.

All that aside, there's no fundamental issue with performing cryptography in JavaScript, except that:

It is typically fairly slow by most standards
Generating cryptographically secure keys can be an issue, particularly in older browsers which don't support certain newer APIs for this task


How is TSC (TKIP sequence counter) calculated, in WPA?

TSC is just a counter used for anti-replay mechanism and it increases by 1 for every MPDU. Thus, its value depends on the sequence of the MPDU. I am not quite certain about its initial value but i suppose it depends on the implementation as usually.


Why is UDP port scanning slower than TCP port scanning?

The difference is in the very nature of the two protocols.

TCP is a connection-oriented protocol. This means that systems must establish and confirm a stable connection - for TCP, the process is commonly known as the "three-way handshake" - before data is actually transferred. As the process must happen quickly for a good connection, it can be reasonably expected that an open TCP port will respond in short order when it is probed. This means that the timeout before assuming a port is closed may also be very short.

UDP, on the other hand, is a connectionless protocol. For UDP, communications are sent without any expectation of a timely confirmation of receipt from the remote end. Thus, one has to allow for a longer timeout before it can be assumed that a remote port is closed - even after the timeout, such assumption is not 100% assured to be valid.

In a certain way, it's kind-of like this:

TCP will call your phone and wait for you to actually pick up in order to warn you of a fire in your workplace. If you pick up and they talk to you, they know you've gotten the message. If your voicemail picks up, or the phone rings >4 times without a re-direct, they can be pretty sure you're not getting the message soon enough.
UDP will send an emergency alert announcement to your phone to tell you of the fire. They won't know if you got the message unless they see you exiting the building, 5 flights of stair-climbing and a 100-meter dash or two later. And that's assuming you were even in the building to begin with.

Now, let's say you had to notify 1,000 or so people about a fire. But you could only tell them one at a time, and had to wait for confirmation of receipt (or a reasonable time to be sure of probable non-receipt) from each one before trying the next.

Port scanning (with Nmap or any other tool) is kinda like that. TCP is gonna go relatively quick, and will probably be pretty accurate. With UDP the building will probably burn down before you get through the list just once, and you still won't be really sure whether the people you sent the message to were even around to care about it.


What is best way to encrypt a blob with public key?

The best way is: don't do it yourself. Use a format/protocol with existing libraries which do the job. Indeed, as with all things crypto, making a working implementation is easy, making a secure implementation is nigh impossible -- especially since you cannot test for security.

In this case, this points to the OpenPGP format and its well-known open-source implementation GnuPG (which is both a command-line tool and a library).

Internally, OpenPGP uses hybrid encryption: a symmetric key is generated and encrypted with the asymmetric (say, RSA) public key; and the symmetric key is used to process the bulk of the data with a symmetric encryption algorithm. But though the concept is interesting to know, the details are best left to a format that has been vetted for by cryptographers, and an implementation which has sustained deployment in production for a decade, and for which most bugs are assumed to have been found and removed.


Pitfalls of using OAuth for mobile Applications

Well the first consideration is that SSL/TLS is absolutely necessary to implement correctly.

One must also consider 2-legged or 3-legged authn mechanisms. While most are going to recommend the more complex (and safe) 3-legged approach, it is possible that 2-legged would have advantages when done right for certain apps.

There have been some timing attack discoveries on OAuth done by rootlabs. There are also risks from XSS/CSRF and ClickJacking (and other attacks against the authn), just like in any web application.

ArsTechnica ran two articles on the OAuth security architecture, one linked from Bruce Schneier.


Is there a way to identify the client using SSL Handshake Messages?

Typically, this scenario is addressed by sending a certificate request anyway and allowing for an empty certificate message (sent by the client) when the certificate is not needed. This is is what mod_ssl's SSLVerifyClient optional does (also the difference between need and want authentication in Java). This is the establish way of dealing with servers for which not all clients may need to present a certificate, and clearly allowed within the TLS specification (Section 7.4.6):

  This is the first message the client can send after receiving a server
  hello done message.  This message is only sent if the server requests
  a certificate.  If no suitable certificate is available, the client
  SHOULD send a certificate message containing no certificates.  That
  is, the certificate_list structure has a length of zero.  If client
  authentication is required by the server for the handshake to
  continue, it may respond with a fatal handshake failure alert.

You might be able to give an hint using the Client Certificate URLs extension, although I don't think this is the intent of this extension (that would be a bit of a trick). I'm not aware of this extension being widely supported, which would certainly cause practical problems if you want to run this on a production system.

If you really don't want the client to be prompted for a certificate in certain cases, what you may be able to do is to use the Server Name Indication (SNI) extension, which is increasingly supported, thereby offering two distinct server configurations depending on which server name the client is requesting. I haven't tried, but I presume that if you configure two distinct virtual hosts with Apache Httpd using SNI, and only one of them is configured to request a client-certificate, you may be able to achieve your goal.

The downside is that you would need to set up two host names for the same server, but that's not as big a deal as other solutions that may require some programming.

For example, even if you assumed that the source IP address was a sufficient discriminator between your two use cases, in Java, you would probably have to implement the server as listening to a plain ServerSocket (not an SSLServerSocket), check from which IP address it's coming from, convert the accepted socket into an SSLSocket in server mode and configure it at the stage (before the handshake has taken place) to request a client certificate or not, and only then trigger the handshake. (I haven't tried any of this, but that would seem a reasonable way to handle such a case.) This would certainly be more complex than creating an SSLServerSocket and accepting pre-configured SSLSockets from it directly. I would imagine that other SSL/TLS stacks (in C or others) wouldn't handle such a case very cleanly either.


First there are different types of hash collisions. The simpler and more likely case it that it is possible to create two documents which result in the same hash value ("collision attack"). The harder case is to find a collision for a specific given document so that both result in the same hash value ("second pre-image attack") or to find a document matching a specific hash value ("first pre-image attack"). This is also the case which has the more security impact.

A major use of SHA-2 is the creation of signatures. If it would be possible to create a document which results in the same hash as another given document one could successfully reuse the signature of the other document. This means it can be used to successfully claim that a document was signed by a specific entity even though this entity never signed this document.
One very important type of such documents are X509 certificates which are used for authentication within TLS (and thus HTTPS). Successfully forging such a certificate thus means that a man in the middle attack could be possible.
Other users of such signatures are S/MIME where forging a signature would mean that one could claim that a specific forged mail was signed by a specific person. And such signatures are also used for signing software and forging a signature here would mean to successfully pass through white lists where the trust to a software (and the ability to execute it) are based on the issuer of this software.

If it is not possible to create a collision to a specific document but to create two documents resulting in the same hash it would still be a serious issue. For example this could be used to create two versions of a contract which both result in the same hash. The cheating party then could later use the previously created different version of the contract with different rules and claim that this is the original version because it contains the same signature.

For more information see RFC 4270 - Attacks on Cryptographic Hashes in Internet Protocols. Interesting might be also Crypto breakthrough shows Flame was designed by world-class scientists where it shows how attacks against the the older hash function MD5 were successfully used in a real-life targeted attack.

  Would there be a greater impact if more than one were found, or would it be the same in principal?

While this might be worse it would probably not be much worse compared to the initial problem.


Are Internet speed tests an attack vector?

Internet speed test is not an attack vector per se.

Flash vulnerabilities might be an attack vector. If Speed test is downloading data from untrusted source - that might be attack vector as well.

XSS, SQLi, other web app vulnerabilities, that can be used on the speed test website, could also be further used to attack it's users.


Blackbox vs whitebox testing your own site?

Blackbox testing gives the perspective of an external attacker while whitebox testing generally gives the perspective of an internal attacker. Those perspectives have a big intersection but have exclusive coverages. Even whitebox testing tending to be easier to do and sounding more effective (not always true though, sometimes whitebox is much harder), tests created by an attacker with no inside information tend to follow a logical path that whitebox testing initially discard, creating a chance of overpassing a vulnerability.

Security is always a trade of cost and benefit. You need to put into balance the chance and the amount of damage of an internal attack versus the cost of whitebox testing. Also do the same thing for an external attacker and blackbox testing. Keeping this cost/benefit relation in mind you can choose one of the the approaches or even both


Should a mobile banking app force clients to change their password periodically, e.g. every 3 months?

The bottom line is: if you are subject to a standards body, follow their guidance. If not, do a security threat assessment.

For instance, government agencies under the US Department of Commerce must, by law, follow the NIST's Digital Identity Guidelines, SP 800-63. For our discussion, the important document is SP 800-63B, covering authentication and lifecycle management.  However, if you're processing payment card information directly, then the standard to follow is the Payment Card Industry Data Security Standards (PCI DSS).

Highlights from the NIST standards:

8 characters minimum
All printing characters in ASCII and Unicode accepted (Support UTF-8)
Smallest allowed maximum length is 64 characters
No password hints
No previously leaked passwords, dictionary words, repetitive or sequential characters, or context-specific words (such as their username again). (Half a billion previously leaked passwords are available for download at Pwned Passwords, or can be checked without leaking your user' desired passwords with the Pwned Passwords API)
Rate limit failed authentication on a host (unique IP address) AND account level
Do not impose rules that force multiple character types (i.e., requiring lower case, upper case, numbers, and symbols). (As above, you must still accept multiple character types.)
Do not require passwords to be changed arbitrarily, such as periodically
Require passwords to be changed if there is evidence of compromise
Permit users to paste passwords (encourages use of password managers)
Allow the user the option (but not default) to display their passwords in plaintext while entering it
Use an encrypted channel (such as TLS)
Store passwords in a salted and hashed form using a one-way key derivation function. (That is, it's not just SHA-256. At a minimum, something like PBKDF2 or better (Balloon, bcrypt, Argon2, etc.))
Salt will be at least 32 bits, generated using a cryptographically secure PRNG, and will be unique to each password.

Many of these requirements are in direct conflict with the PCI standards. If you handle payment card information directly (that is, any of your customer service representatives handle credit/debit cards over the phone), then the system that they use to handle those payments has a whole different set of requirements.

Highlights of the PCI standard are:

7 characters minimum
Force multiple character types in the same password
Change passwords every 90 days
Can not re-use the last 4 passwords
Users can not set their first password, nor the password immediately after a reset
Passwords must be changed when entering a first or reset password
Accounts locked for at least 30 minutes or until an admin resets the lock if authentication fails 6 times
Sessions expire after 15 minutes of idle time
Use an encrypted channel (such as TLS)

Further, the NIST standards state that you should use 2-factor authentication wherever it's possible, such as the Time-based One Time Password standard (a.k.a., Google Authenticator), printable sheets of single-use tokens, and U2F devices that perform cryptography inside a device like a USB stick.

If you're neither an employee of the US federal government nor handling payment cards directly, and there are no standards bodies that have rules specific to your country, your industry, or practices that your company is using, then you need to do a security threat assessment, including cost/benefit analysis, and design your authentication system around that.

Your conclusions may likely be different from mine. I personally follow the NIST standards as much as it makes sense. I found it very low cost and low risk to use the Pwned Passwords API to let my users know if they used a previously leaked password. However, unlike the NIST standards, I do allow my users to have a previously leaked password, showing a message stating that the password was successfully changed, but that it had been included in X number of data breaches in the past and may be used by hackers in the future. I use the message as an opportunity to raise awareness of the dangers of password reuse, introduce the concept of password managers generating truly random passwords, and I get to show off my Yubikey U2F dongle.  I have the luxury of being face-to-face with most of my users, though.


Recover key in HMAC-SHA256 message authentication

If you want to protect the message then you have a serious problem, because it can be easily decoded with:

crypto = "546869732069732061206c6f6e67206d6573736167652074686174206d696768742062652061206c6974746c6520746f6f206c6f6e67"
print crypto
print crypto.decode('hex')

But since you've asked to retrieve the password via dictionary attack, I made a script that decodes the hex to plaintext which is then used as a salt in HMAC along with passwords in dictionary and SHA256 to produce hashes(mimicking the original HMAC function) which are then compared to the targeted hash string:

import hmac
from hashlib import sha256

hashd = 'e3762ae7f3bc6c9f8906e5f1f2cd19e80d3ebd281bdd31119a66adaef33d3b3c'
crypto = '546869732069732061206c6f6e67206d6573736167652074686174206d696768742062652061206c6974746c6520746f6f206c6f6e67'
decrypto = crypto.decode('hex')
keys = open('dictionary.txt').read().split() # Specifiy the path to the dictionary file

def mykey():
   for i in keys:
     digest=hmac.new(i, decrypto, sha256)
     digest.hexdigest()

     if digest.hexdigest()==hashd:
        print 'password:', i
        break

if mykey():
   print mykey()

So if the password is in the dictionary, it will print it out. Tested in python 2.7. Also note that the words have to be one per line in the dictionary for this to work properly.

EDIT: Here is a more flashy version, in case you need it for presentation:

import hmac
from hashlib import sha256
from datetime import datetime
startTime = datetime.now()

hashd = raw_input('SHA256: ')
crypto = raw_input('HEX: ')
decrypto = crypto.decode('hex')
keys = open('dictionary').read().split() # Specifiy the path to the dictionary file

def mykey():
   for i in keys:
      digest=hmac.new(i, decrypto, sha256)
      print digest.hexdigest(), '-', i

      if digest.hexdigest()==hashd:
         print 'Password found:', i
         break
   else:
      print 'Password not in the dictionary.'

if mykey():
   print mykey()

print 'Time Elapsed:', datetime.now() - startTime


Can a forwarding rule be set on Outlook that will not be visible on office365/exchange admin interface?

Generally there are multiple Ways to forward E-Mails:

Users can create a forwarding rule within Outlook or Outlook Web App
An administrator can create a client rule for forwarding
An administrator can set the ForwardingSMTPAddress parameter on a mailbox
Users can set the ForwardingSMTPAddress parameter on a mailbox
An administrator can set the ForwardingAddress parameter on a mailbox

You can check which Mailboxes have external forwarding enabled via Powershell, as this Post suggests.

Get-Mailbox -ResultSize Unlimited -Filter {(RecipientTypeDetails -ne "DiscoveryMailbox") -and ((ForwardingSmtpAddress -ne $null) -or (ForwardingAddress -ne $null))}

If you want to disable external forwarding of Mails in General, this Microsoft Guide will help you.


Locking an enterprise account from an internet facing application

You could try to implement a captcha on the logging page of the web application after the first try to reduce DoS situations.

Also, banning the IP which has several failed logging attempts could help prevent such situation. fail2ban is commonly used in UNIX environments for this purpose.

Also, using unpredictable usernames could reduce the risks.


Is this code snippet good enough for password hash and salt

It's easier to use the php 5.5 password_hash function, or if you're using an older version, the compatibility library
openssl_random_pseudo_bytes sometimes suffers from performance issues. Consider mcrypt_create_iv (size, MCRYPT_DEV_URANDOM) instead.
salt encoding is tricky. Hex doesn't use the space optimally, and normal Base64 uses invalid characters.

$salt = substr(strtr(base64_encode($randomSalt), '+', '.'), 0, 22);

should do the trick.

Combining these you get

$binarySalt = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM);
$salt = substr(strtr(base64_encode($binarySalt), '+', '.'), 0, 22);

Check Seven Ways To Screw Up BCrypt on ircmaxell's blog for further reading.


How can we avoid the Facebook SDK? General: Trusted forge for Android apps?

When you are installing one such app, it should show you an EULA explicitly saying that what they are going to share, with whom, etc. Specially if you are in Europe and the treatment of your PI is subject to GDPR.

The main problem as I recall it is that developers themselves were not even aware of what was being shared by using the Facebook SDK. So it wasn't being included in the EULA, nor would users be aware of what was going on.

Technically, the app developer is the one in fault here (the one you would have to sue if really wanted, etc.) while you are the loser and Facebook always winning.


The key used in HMAC is, by definition, symmetric: the same key is used to compute the MAC value, and to verify the MAC value. Digital signature algorithms are asymmetric, which means that the key for verification is distinct from the key used for generation; this "difference" is strong: the key used for generation cannot be recomputed from the key used for verification (at least, nobody found a way to do that in a non-ridiculous time with existing technology).

Digital signatures make sense in situations where the verifier must be able to verify signatures, but without being granted the power to generate other signatures of its own. This is typical of non-repudiation scenarios: only the signer must be able to produce valid signatures, otherwise the signature cannot be unambiguously attributed by third parties (e.g. a judge) to that specific signer. However, in authentication scenarios such as Amazon AWS, there is no third party to convince; there is only the client and Amazon. When a HMAC value is successfully verified, the Amazon server is convinced that someone knowing the HMAC key was involved; since that key is known only to the client and the server itself, and the server remembers not having used the key for that message himself, the server easily concludes that the client computed the HMAC.

Digital signatures imply some overhead:

More CPU: generating a digital signature and verifying a digital signature requires more work than HMAC (difference is negligible for big messages, but can be significant for small messages of less than a few kilobytes).
More network bandwidth: a very robust HMAC value fits in 16 bytes, whereas an equivalently robust RSA signature will use 256 bytes (this can be lowered to about 64 bytes with DSA or ECDSA). There again, this is significant when processing lots of small messages.
More storage size: a RSA public key (for verification) will use 256 bytes; the private key will use more (about one or two kilobytes). ECDSA can help, to some extent (down to about 32 bytes for either key), but it is still larger than the 16 bytes for a HMAC key.
Randomness: many digital signatures require some per-signature randomness, which must be obtained from a cryptographically secure PRNG.
More complexity: mathematics and code involved in digital signatures are more complex than HMAC (HMAC is just a pair of hash function invocations; digital signatures begin with a hash function invocation, and then do weirder things). For security, complexity is bad.

So you do not want to use digital signatures in contexts which can be equally well served with a simpler HMAC. In my view, the most compelling reason is the last one: complexity should be avoided.


How to secure a network (FTP connections) from sniffers

If I understand correctly, your connection to the Internet gateway is wired and everyone else is WiFi.  If that is the case, the WiFi users cannot capture your FTP credentials because there is no need for the WiFi AP to transmit them, and it won't.

But really, the answer is to convince the people at the other end to replace FTP with SFTP.


Go with RSA.
DSA is faster for signature generation but slower for validation, slower when encrypting but faster when decrypting and security can be considered equivalent compared to an RSA key of equal key length. That's the punch line, now some justification.
The security of the RSA algorithm is based on the fact that factorization of large integers is known to be "difficult", whereas DSA security is based on the discrete logarithm problem. Today the fastest known algorithm for factoring large integers is the General Number Field Sieve, also the fastest algorithm to solve the discrete logarithm problem in finite fields modulo a large prime p as specified for DSA.
Now, if the security can be deemed as equal, we would of course favour the algorithm that is faster. But again, there is no clear winner.
You may have a look at this study or, if you have OpenSSL installed on your machine, run openssl speed. You will see that DSA performs faster in generating a signature but much slower when verifying a signature of the same key length. Verification is generally what you want to be faster if you deal e.g. with a signed document. The signature is generated once - so it's fine if this takes a bit longer - but the document signature may be verified much more often by end users.
Both do support some form of encryption method, RSA out of the box and DSA using an El Gamal. DSA is generally faster in decryption but slower for encryption, with RSA it's the other way round. Again you want decryption to be faster here because one encrypted document might be decrypted many times.
In commercial terms, RSA is clearly the winner, commercial RSA certificates are much more widely deployed than DSA certificates.
But I saved the killer argument for the end: man ssh-keygen says that a DSA key has to be exactly 1024 bits long to be compliant with NIST's FIPS 186-2. So although in theory longer DSA keys are possible (FIPS 186-3 also explicitly allows them) you are still restricted to 1024 bits. And if you take the considerations of this [article], we are no longer secure with 1024 bits for either RSA or DSA.
So today, you are better off with an RSA 2048 or 4096 bit key.


Is it alright to tell everyone your encryption information?

It's not just alright, it's actually a design feature of modern ciphers. The whole concept of cryptography is that you can freely publish the algorithm used, but must keep secret a specific piece of information, called the key.

  password is encrypted using a one-way 160-bit hash cryptographic algorithm

Encrypted is the wrong word here - this is not encryption; rather, it's hashing. Encryption is a reversible process where recovery of the data is the aim of the game. A hash function, however, is designed such that it is "one way", i.e. it is trivial to take a given input and produce the hash, but hard to go backwards.

If you think about it, this makes an awful lot of sense - the bank don't need to know your password; they only need to know that the person entering the password has entered the same one as you initially told them. So, by storing the hash of your password, they can compare future password inputs against that password and voila! They need not know the password, but they can check it.

Technically, they're on the right lines; 160 bits suggests an SHA1 or RIPEMD160 algorithm. However, if a simple hash is all they do, there is more they can do to improve security:

Use a salt value, ideally uniquely generated per password.
Use a slow hashing function such as PBKDF2.


Is Linkedin, Google and Facebook Running BitTorrent client?

The simple answer to your question is:

No, Linkedin, Google and Facebook are not running a BitTorrent client

If your sensor is triggering only on the use of port 6881, then it could be set off by anything that uses that port. As most applications dynamically assign ports, this could explain why you haven't managed to recreate it.

The solutions:

Don't use a sensor that works solely by matching port
Limit applications to specific port ranges


What algorithms can be used for device pairing?

On reread I think I see what you are trying to accomplish.  User has an account on www.example_business.com and now wants to use example business's new android app.  You have decided you do not want the user to have to give full login through your android app.  Maybe you require two-factor authentication (where the second factor is the phone), or require certificates, or are afraid of carrier-IQ type keyloggers and do not want to do the full login procedure on the phone.

Client opens mobile_app for first time, which asks user for their user_name, and then sends a request to server for token with user_name.  (If user_name doesn't exist; do not communicate to mobile app).
Server generates random_number (say ten digit base36 with 36^10 ~ 10^15 possibilities initial displayed as lowercase to easily distinguish 0 from O) and sends this to the website.  Server sends timestamp + sha256hash(timestamp + user_name + random_number + high_entropy_secret_key_only_known_by_server) to Mobile app and instructions to logon to the website to get the random_number.  The high_entropy secret key should be something like: TQy9p4pDDHpZuS3Fimdag6yCtU9YBCt55PntmPyUPD_oxRMW3f that's kept secret on the server.
Client logs onto website, reads random_number, and types random_number into mobile-app.
Mobile app sends timestamp (from step2), user_name, received hash (from step2) and random_number (from step3) back to server.
Server checks that the timestamp is not too old (say less than a day), has not been blacklisted from too many bad attempts, checks that the hash matches the hash of the received data (does this case-insensitive; e.g., lowers case of random_number), and then sends a token to the mobile app linking the two accounts.

As for blacklisting after too many bad attempts; I'd blacklist usernames+timestamps that have failed three times; you can empty out the blacklist every day (since only day old timestamps work); have mobile app restart process with new timestamp/random_number).

I'd use SSL for all transmissions to prevent eavesdroppers.  Now for a user not having an account but knowing a valid user_name and trying to brute-force the random number, they'd have a 1 in 10^15 (about 20 million times less likely then winning the lottery) chance of guessing correctly per attempt.  But I'd further institute a step where you throttle logins for IP addresses and accounts that are failing syncing attempts too many times.


Relative Strength of Automated Password Suggestions

The "phrase of random words" is much easier to remember

The text duplicate.aught.cavemen.length is easier to remember than 1202.8746.9173.0953. The problem with the latter is that you need to remember the right digits in a search space where there's no meaning attached to it (Was it 9173 or 9174?). You can have some doubts with the words (perhaps trying cavemen or troglodyte), but in the end, the familiar dictionary makes it is easier to remember.


Is it safe to use public USB charging stations?

Depends on the phone. If you've disabled USB debugging/file sharing1, then Android phones are inaccessible via USB until you turn it on.

On the other hand, one can access most files of an iPhone without any special access (this bypasses the pincode lock as well). Desktop applications like IExplore do this. While ssh access won't be available, they still can delete/steal your data, including applications, music, photos, and videos. As well as the configuration of applications (which may include passwords). And they can add their own malware.

1 These two are different. Most phones have debugging enabled by default, though you can turn it off. USB sharing is disabled by default, since it requires the SD card to be unmounted (which kills half your apps).


Should my webhost show the root filesystem over FTP?

Calling this a security issue is probably too loud. Hiding the system files is only obfuscation, and we all know that obfuscation is not one of the best security practices.

But on the other hand, the least priviledge rule is. That means a user or a account should only have allowed accesses for what is required for its job or contract. Here clearly, you would have no reasons to be able to browse the root folder.

I still would not call it a security issue, unless you are able you look at the data of other customers (because that means that than can also access yours), but is probably a hint that the administrator is not really attentive to the best security rules. As such this is a hint that other more serious security issues could exist on this webhost.

But anyway, it is only a hint, not an evidence.


How does this implementation of full disk encryption work?

From what I can find on Sophos website, it looks like the encryption keys and revelant certificates are stored on a mssql database which holds the information.

  The SafeGuard Enterprise Database(s) hold all relevant data such as
  keys/certificates, information about users and computers, events and
  policy settings. The database(s) need to be accessed by the SafeGuard
  Enterprise Server and by one security officer only through the SafeGuard
  Management Center, usually the Master Security Officer. The SafeGuard
  Enterprise Database(s) can be generated and configured using a wizard
  or scripts.
  http://www.sophos.com/en-us/medialibrary/PDFs/documentation/sgn_61_ig_eng_installation.pdf?la=en


mis-use of email address to obtain services from Groupon

The user, intentionally or accidentally, likely left a mocked email address of which GroupOn did not validate. As a result, you were able to identify as the account holder because you were able to access the account's email. This is the users' problem for using mocked emails for their account and is a living example of why email verification is important.


1) What that seems to be telling you is that the vulnerable server that you are looking into is on the same network as your Kali Linux machine. This means that you should be able to find it by scanning your local network.

2) To start using nmap I suggest that you run the command man nmap in your terminal and read through the information there that should give you a good idea of where to start. You can also go to https://nmap.org and read through the reference guide provided by nmap. That is the best way to learn how to use this tool. Play around with the features that come with it and read up on the things that you do not understand this will help you to gain a better understanding of using nmap and analyzing networks.


Why can't sqlmap find an SQL injection in my code?

There is a huge probability, that your server doesn't display any errors/warnings. Sqlmap tries to inject sql inj.-like payloads and observes the webapp "state". As sqlmap hasn't got an access to your vulnerable code or DB content it could just only guess the potential vulnerability by observing webapp behaviour – in this case „visual” behaviour (no warnings/errors – no potential sql-inj.).

However, sqlmap gave you pretty nice hint: try to increase level/risk values:

    python sqlmap.py -u "http://..." --level=3 --risk=3

after that change you will increase the amount of payloads (sent to your webapp) and you will find blind sql.inj!. It means that on level 3 (and --risk=3) sqlmap doesn't check only „visible” effects. It uses some time-taking operation [BENCHMARK()] which delays server response if sql. Inj. occurs.


IP reputation lists of malicious/suspicious IPs (paid or free)

Brightcloud makes a great product that gets update frequently: https://www.brightcloud.com/

There are a lot of open source lists, but I personally find that they tend to have a lot of stale data.


You'll need to look at the PA-DSS certification process from the PCI Security standards council.

They have information on the standard and certification procedures on their website https://www.pcisecuritystandards.org/hardware_software/


Is it possible to prevent an attacker from capturing my WI-FI handshake on WPA-2 AES?

No, it's not possible to prevent someone from capturing the handshake.

A properly implemented password with enough entropy can withstand even a very well funded attacker. The example hash rates given for the highest end machine are still only about 1 million hashes a second on a machine with 8 GPUs.  In a year you could do 1,000,000*60*60*24*365=3*10^13 passwords, or about 44 bits.  If you really want to be secure, generate a random 128 bit password, and print it on your router.  This will be secure from any brute force attempt, though it won't save you from rubber hose cryptanalysis.


How to obtain trusted certificates for use with OpenSSL in C (on a Mac)?

Since OpenSSL traditionally cannot easily access the native trust store on Windows and Mac the common way for OpenSSL based applications on these platforms is to use the same set of trusted certificates as Firefox does, which also comes with its own trust store on all platforms and does not use the native one. This set can be downloaded at CA certificates extracted from Mozilla. It then gets set with SSL_CTX_load_verify_locations for the specific SSL context as you already figured out (SSL_CTX_use_certificate_file and related is for loading client certificates and not the  trust store).


The standard answers is, use secure connections from the frontend to the backend servers as well.

In the following situation it may be okay and common to use unencrypted connections:

The network infrastructure between frontend and backend is considered secure. For example a dedicated hardware network which ensures that no unauthorized sniffing or modification of traffic is possible. The switch should be setup in a way that prevents ARP cache poisoning and ARP cache flooding because servers might fall victim to an attack and turn hostile.
And the traffic is so high that decryption poses a significant load on the backend servers.


Can a javascript on parent page log keystrokes inside an iframe?

1)Yes

2) No (although plugins could in theory alter this behaviour, but I do not know of any myself)

3)Unless there is a vulnerability exploited in a browser that is yet to be patched, or the use of a malicious/rogue browser, then no you cannot


Micrsoft Threat Modeling Tool 2016 make a bi-directional connect

Select the two processes and right click Bi-directional.