Tag Archives: Security

Removing the Server Header in ASP .NET Core

There are many aspects to web security, but in this article we’ll focus on one in particular. Attackers can use any available information about a target web application to their advantage. Therefore, if your web application is sending out headers revealing the underlying infrastructure of your web application, attackers can use those details to narrow down their attack and attempt to exploit vulnerabilities in that particular software.

Let’s create a new ASP .NET Core web application to see what is returned in the headers by default:

mkdir dotnet-server-header
dotnet new web
dotnet run

This creates a “Hello world” ASP .NET Core application using the “ASP .NET Core Empty” template, and runs it. By default it runs on Kestrel on port 5000. If we access it in a browser and check the response headers (e.g. using the Network tab of the Chrome Developer Tools), we see that there’s this Server header with a value of Kestrel. If it were running under IIS, this value might have been MicrosoftIIS/10.0 instead.

Honestly, this could be worse. Older versions of ASP .NET running on the old .NET Framework used to add X-Powered-By, X-AspNet-Version and X-AspNet-MvcVersion headers with very specific information about the underlying software. While this information can be really useful for statistical purposes (e.g. to identify the most popular web servers, or to identify how prevalent different versions of ASP .NET are), they are also very useful for malicious purposes (e.g. to look for known vulnerabilities in a specific ASP .NET version).

ASP .NET Core, on the other hand, only adds the Server header, which is quite broad. However, the less information we give a potential attacker, the better for us.

There is no harm in removing the Server header, and to do this in ASP .NET Core, we can take a tip from this Stack Overflow answer:

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>()
                              .UseKestrel(options => options.AddServerHeader = false);
                });

The highlighted line above, added to Program.cs, has the effect of getting rid of that Server header. In fact, if we dotnet run again now, we find that it is gone:

Update 27th July 2020: Just to clarify, this removes the Server header coming from Kestrel. However, if you use other software (e.g. IIS) to host your web application, you will need to take additional steps to remove it from there as well.

It is always a good idea to do a vulnerability assessment of your web application, and in doing so, remove any excess information that complete strangers do not need to know. What we have seen here is a very small change that can reduce the security risk at least by a little.

Encrypting Strings in C# using Authenticated Encryption

Encryption is fundamental and ubiquitous. Whether it’s to prevent sensitive settings (such as passwords and API tokens) from falling into the wrong hands, or making sure no one listens in on confidential communications, encryption is extremely important. Many people do not even realise that they use it every day.

Encrypting data using the .NET Framework or .NET Core libraries, however, is not trivial. There are different ways to encrypt and decrypt data, and sometimes this requires some knowledge about the underlying algorithm.

To keep things really simple, we’ll use a third party library that provides a simple interface for encryption and decryption. Because this library uses strings and byte arrays, it is not suitable for encryption of large amounts of data, such as huge files, which would bloat the application’s memory. However, it is perfectly fine for small strings.

Later in the article, I also share a simple tool that I built to help generate keys and test encryption and decryption. You can find this tool under the AuthenticatedEncryptionTester folder in the Gigi Labs BitBucket repository.

Using AuthenticatedEncryption

AuthenticatedEncryption is a library that provides simple methods for encryption and decryption:

“The library consists of a single static class. This makes it very easy to use. It uses Authenticated Encryption with Associated Data (AEAD), using the approach called “Encrypt then MAC” (EtM). It uses one key for the encryption part (cryptkey) and another key for the MAC part (authkey).”

All we need to start using this is to install the corresponding NuGet package, either using the Package Manager Console:

Install-Package AuthenticatedEncryption

…or using the .NET Core command line tools:

dotnet add package AuthenticatedEncryption

The project’s readme file (which is the first thing you see in the GitHub repo) explains how it’s used, and it is really simple. First, you generate two keys, called the cryptkey and authkey respectively:

var cryptKey = AuthenticatedEncryption.AuthenticatedEncryption.NewKey();
var authKey = AuthenticatedEncryption.AuthenticatedEncryption.NewKey();

This is something you will typically do once, since you have to encrypt and decrypt using the same pair of keys.

Next, we need something to encrypt. We can get this from user input:

Console.Write("Enter something to encrypt: ");
string plainText = Console.ReadLine();

We can now encrypt the plain text by using the keys we generated earlier:

string encrypted = AuthenticatedEncryption.AuthenticatedEncryption
    .Encrypt(plainText, cryptKey, authKey);
Console.WriteLine($"Encrypted: {encrypted}");

And we can also decrypt the cipher text using a similar mechanism:

string decrypted = AuthenticatedEncryption.AuthenticatedEncryption
    .Decrypt(encrypted, cryptKey, authKey);
Console.WriteLine($"Decrypted: {decrypted}");

You will by now have noted the double AuthenticatedEncryption that is constantly repeated throughout the code. This is a result of the unfortunate choice of the library author to use the same for the class and namespace. There is already an open issue for this.

Update 20th July 2020: this syntactical problem was recently fixed by renaming the class. As from version 2.0.0, once you have your using AuthenticatedEncryption;, you can call the relevant methods directly on the static Encryption class, such as Encryption.NewKey().

Let’s run this code and see what happens:

Simple encryption and decryption using the AuthenticatedEncryption library. Running on Kubuntu 19.10 using .NET Core.

As you can see, the input string was encrypted and the result was encoded in base64. This was later decrypted to produce the original input string once again.

Authenticated Encryption Tester

To facilitate key generation as well as experimentation, I wrote this small tool:

Authenticated Encryption Tester. A simple tool to quickly use the functions of the AuthenticatedEncryption library.

This lets you use the AuthenticatedEncryption library functionality that we have just seen in the previous section. It’s useful to initially generate your keys, and also to test that you are actually able to encrypt and decrypt your secrets successfully.

It is a WPF application running on .NET Core 3, so unlike the AuthenticatedEncryption library, unfortunately it only works on Windows. However, for those of you who, like me, have the misfortune of already using Windows, it can turn out to be a handy utility.

You can get the code from the AuthenticatedEncryptionTester folder in the Gigi Labs BitBucket repository. While I won’t go through all the code in the interest of brevity, I’d like to go through some parts and show that it’s doing pretty much what we’ve seen in the previous section.

        private void GenerateCryptKeyButton_Click(object sender, RoutedEventArgs e)
            => GenerateKeyInTextBox(this.CryptKeyField);

        private void GenerateAuthKeyButton_Click(object sender, RoutedEventArgs e)
            => GenerateKeyInTextBox(this.AuthKeyField);

// ...

        private void GenerateKeyInTextBox(TextBox textBox)
        {
            string key = AuthenticatedEncryption
                .AuthenticatedEncryption.NewKeyBase64Encoded();
            textBox.Text = key;
        }

The first two fields in the window expect to have the two keys in base64 format. You can either use keys you had generated earlier and stored, or you can hit the Generate buttons to create new ones. These buttons create new keys using the NewKeyBase64Encoded() method, which is just like NewKey() except that it returns a base64-encoded string instead of a byte array. This is handy in situations where you want a string representation, such as in a GUI like this.

Encryption and decryption also work just like in the previous section, and the implementation merely adds some extra code for validation and I/O. This is the method that runs when you click the Encrypt button:

        private void EncryptButton_Click(object sender, RoutedEventArgs e)
        {
            const string operation = "Encrypt";

            string cryptKeyBase64 = this.CryptKeyField.Text;
            string authKeyBase64 = this.AuthKeyField.Text;
            string plainText = this.PlainTextField.Text;

            try
            {
                if (string.IsNullOrWhiteSpace(cryptKeyBase64)
                    || string.IsNullOrWhiteSpace(authKeyBase64)
                    || string.IsNullOrWhiteSpace(plainText))
                {
                    ShowWarning("Both keys and the plain text must have a value.",
                        operation);
                }
                else
                {
                    byte[] cryptKey = Convert.FromBase64String(cryptKeyBase64);
                    byte[] authKey = Convert.FromBase64String(authKeyBase64);

                    string cipherText = AuthenticatedEncryption
                        .AuthenticatedEncryption.Encrypt(plainText, cryptKey, authKey);
                    this.CipherTextField.Text = cipherText;
                }
            }
            catch (Exception ex)
            {
                ShowError(ex, operation);
            }
        }

The Encrypt button takes what’s in the Plain Text field and puts an encrypted version in the Cipher Text field. The Decrypt button does the opposite, taking the Cipher Text and putting the decrypted version in the Pain Text field. The code for the Decrypt button is very similar to that of the Encrypt button so I won’t include it here.

One thing you’ll note as you experiment with this is that the encrypted output string changes every time. This is an expected behaviour that provides better security. By clearing the value in the Plain Text field before hitting Decrypt, you can verify that it is always decrypted correctly to the original input string, even with different encrypted values.

Summary

The AuthenticatedEncryption library is great for encryption and decryption of simple strings. For large amounts of data, you should instead use streams together with the cryptographic APIs available in the .NET Framework or .NET Core.

You can use my Authenticated Encryption Tester to generate keys or experiment with encryption and decryption using the AuthenticatedEncryption library. It is built on WPF so it only works on Windows.

Using Time-Based One-Time Passwords for Two-Factor Authentication

Introduction

Two-factor authentication (2FA) is becoming more and more important, as its adoption is driven by a need for major software companies to secure their systems against threats, as well as due to legal requirements of strong customer authentication, such as the PSD2 directive that came in force in Europe last month.

2FA can be implemented in a number of ways. Typically, it is a combination of the usual username/password login as well as something else, often being a one-time password (OTP) that is sent via SMS or email, or generated by an algorithm.

In this article, we’ll focus entirely on generating and verifying Time-Based One-Time Passwords (TOTP) using Google Authenticator and the Otp.NET library.

Update 20th October 2019: This also works if you use Microsoft Authenticator instead of Google Authenticator. Microsoft Authenticator requires more permissions on your device, sends usage data to Microsoft by default, and is slightly more confusing because you have to choose the type of account.

Update 22nd October 2019: I discovered another mobile app called Authy, and it works just as well to acquire the TOTP secret and generate codes. It is interesting because it has a mechanism to take encrypted backups in the cloud and synchronise across devices, addressing the problem of when you lose or change your phone.

About TOTP

TOTP is an algorithm used to generate one-time passwords based on a shared secret and the current time. It is defined in RFC6238, and is a variant of the HOTP algorithm (RFC4226) which uses a counter instead of time.

The client and server use the same algorithm, the same shared secret and (roughly) the same time to generate the same code.

TOTP can be thought of as a function that takes the shared secret and current time as inputs, and generates a one-time password as output. Given that the client and server both know the same shared secret, and that their software clocks are more or less in sync without major clock skew, then they would generate the same code. This allows a code generated on a mobile device to be verified on the server side.

Generating a Shared Secret

We will use Otp.NET to perform most operations related to TOTP generation and verification. This can easily be intalled in a .NET (Core) console application via NuGet:

Install-Package Otp.NET

It is then really easy to generate and output a shared secret using the following code:

var secret = KeyGeneration.GenerateRandomKey(20);
var base32Secret = Base32Encoding.ToString(secret);
Console.WriteLine(base32Secret);

The secret that we generated on the first line is an array of bytes. However, we output it in base32 encoding. This is important for the next step when we will pass the secret to the mobile device. As I learned the hard way, it does not work if the secret is an arbitrary string and not base32-encoded.

Running the above, I just got the following in the output:

6L4OH6DDC4PLNQBA5422GM67KXRDIQQP

Generating a QR Code for the Secret

Stefan Sundin made this great 2FA QR code generator. The two required fields are the Secret (where we paste the value generated above) and a Label (which is arbitrary and identifies the application — we’ll simply put “MFA Test 1” in there).

The QR code helps to synchronise the secret between the server and the mobile device.

Setting up Google Authenticator

Find Google Authenticator in your phone’s app store and install it. It requires access to your camera as we’ll see in a second.

Get Google Authenticator from your phone’s app store.

After installation and its brief in-built tutorial, you get to the point where you can set up your first TOTP code generator (they call it an “account”):

To synchronise a shared secret onto your mobile device, you can scan a barcode or type in the secret directly.

This step is where you enter the shared secret into Google Authenticator. You can do that by scanning a QR code (first option), or by typing it in (second option). The latter is slow and painful, especially on a mobile device, and should be kept as a fallback in case there is some kind of problem scanning the QR code. Scanning the QR code is really just a convenience mechanism and is an encoded version of the same secret.

Scan the barcode to get the shared secret into Google Authenticator.

Once you’ve scanned the QR code, Google Authenticator has acquired the shared secret and starts generating TOTP codes every 30 seconds:

Google Authenticator is generating TOTP codes.

Since you can have more than one of these code generators in here (for different applications), they come with a label. In this case, you’ll notice that we have “MFA Test 1”, which is exactly what we entered in the Label field when generating the QR code.

Generating TOTP codes from Otp.NET

If you need to generate TOTP codes from .NET code (essentially to do what Google Authenticator is doing), then Otp.NET makes it very easy to do that:

            string base32Secret = "6L4OH6DDC4PLNQBA5422GM67KXRDIQQP";
            var secret = Base32Encoding.ToBytes(base32Secret);

            var totp = new Totp(secret);
            var code = totp.ComputeTotp();

            Console.WriteLine(code);

The ComputeTotp() method takes an optional DateTime parameter as the current time to use for the code generation algorithm. If not provided, it uses DateTime.UtcNow, which is typically what you want to use.

The TOTP code generated from the C# program (top right) is identical to the one generated from Google Authenticator on my phone (bottom centre).

Since we are using Google Authenticator, we don’t actually need this at all, so this is just something to keep in mind if you ever actually need it. It also gives some assurance that we’re on the right track, because what we’re doing in C# and on the mobile device are evidently well in sync.

Verifying TOTP Codes

Like every other operation we’ve seen, verifying TOTP codes with Otp.NET is also very easy. The following code shows how to do this, although most of the code is actually handling input and output.

            string base32Secret = "6L4OH6DDC4PLNQBA5422GM67KXRDIQQP";
            var secret = Base32Encoding.ToBytes(base32Secret);

            var totp = new Totp(secret);

            while (true)
            {
                Console.Write("Enter code: ");
                string inputCode = Console.ReadLine();
                bool valid = totp.VerifyTotp(inputCode, out long timeStepMatched,
                    VerificationWindow.RfcSpecifiedNetworkDelay);

                string validStr = valid ? "Valid" : "Invalid";
                var colour = valid ? ConsoleColor.Green : ConsoleColor.Red;
                Console.ForegroundColor = colour;
                Console.WriteLine(validStr);
                Console.ResetColor();
            }

Here’s what it might look like while you test it out repeatedly:

A number of tests show interesting results.

As you can see above, I did a number of things:

  1. I entered two invalid codes, and got invalid responses.
  2. I entered a valid code, and got a valid response as expected.
  3. I waited for a new code to be generated, then entered the same code as before, and it was accepted.
  4. I entered the new code that was generated, and it was validated.
  5. I entered another invalid code, and it was marked as such.

The most interesting part of the above is the third step, and it requires further explanation. Codes are generated in time windows, by default every 30 seconds. That doesn’t necessarily mean that the previous code should be rejected. The time window might have shifted just as the user was typing the code, or there could be network delays, etc. Typically, some leeway is allowed when validating these codes. The RFC recommends allowing codes from one time window in the past or future, and that’s what the value of VerificationWindow.RfcSpecifiedNetworkDelay that we passed in as the third parameter to VerifyTotp() does. If you want, you can pass in something different that is more lenient or more restrictive.

On the other hand, accepting the same code twice is wrong, considering we are supposed to be generating one time passwords. In order to make sure that a code isn’t used twice, we need to store something that we can later check to know whether a code has been used. That’s the reason for the second parameter to VerifyTotp(). It gives us back a number indicating the time step used, so we can save this whenever a code is used, and later check whether the same time step has already been used before.

Assuming a single shared secret, a very quick-and-dirty dummy implementation using a HashSet instead of real persistence could look something like this:

            string base32Secret = "6L4OH6DDC4PLNQBA5422GM67KXRDIQQP";
            var secret = Base32Encoding.ToBytes(base32Secret);

            var totp = new Totp(secret);

            var usedTimeSteps = new HashSet<long>();

            while (true)
            {
                Console.Write("Enter code: ");
                string inputCode = Console.ReadLine();
                bool valid = totp.VerifyTotp(inputCode, out long timeStepMatched,
                    VerificationWindow.RfcSpecifiedNetworkDelay);

                valid &amp;= !usedTimeSteps.Contains(timeStepMatched);
                usedTimeSteps.Add(timeStepMatched);

                string validStr = valid ? "Valid" : "Invalid";
                var colour = valid ? ConsoleColor.Green : ConsoleColor.Red;
                Console.ForegroundColor = colour;
                Console.WriteLine(validStr);
                Console.ResetColor();
            }

Sorry about that &amp; in there – the operator is supposed to be &=. There’s a glitch in the editor I’m using and I hope it’ll be sorted out at some point.

Like this, there’s no way you can ever have the same code be valid twice:

The same code, even within the same time window, is invalid the second time.

Conclusion

In this article we’ve seen how Time-Based One-Time Passwords can be generated and verified. We’ve focused mainly on:

  1. Generating a shared secret using Otp.NET
  2. Bringing it to a mobile device with Google Authenticator
  3. Using Google Authenticator to generate TOTP codes
  4. Using Otp.NET to validate these codes

In a two-factor authentication implementation, this is of course only one of the factors, and usually takes place after a regular username/password login.

Lost in Cyberspace in February 2017

This article continues the series started with “The Sorry State of the Web in 2016“, showing various careless and irresponsible blunders on live websites.

Virtu Ferries

A friend reported that the website for Virtu Ferries accepts credit card details over a non-HTTPS connection, specifically when you create a new booking. When I went in and checked, I confirmed this, but also found a number of other issues.

We can start off with a validation error that appears in an orange box in Italian, even though we are using the English version of the website:

Then, we can see how this website really does accept credit card details over an HTTP (as opposed to HTTPS) connection:

This is similar to Lifelong Learning (refer to “The Sorry State of the Web in 2016” for details on that case and why it is bad) in that it uses an HTTPS iframe within a website served over plain and unencrypted HTTP. I have since confirmed that this practice is actually illegal in Malta, as it violates the requirements of the Data Protection Act in terms of secure transmission of data.

Given that the website accepts credit card details over an insecure connection, you obviously wouldn’t expect it to do any better with login forms and passwords:

If you take long to complete the booking, your transaction times out, and you are asked to “Press Advance to Retry”:

 

But when you do actually press the Advance button, you get a nice big ASP .NET error:

This is really bad because not only is the website broken, but any errors are actually visible from outside the server, as you can see above. This exposes details about what the code is doing (from the stack trace), third party libraries in use (Transactium in this case), and .NET Framework and ASP .NET versions. This is a serious security problem because it gives potential attackers a lot of information that they can use to look for flaws in the web application or the underlying infrastructure.

Lost in Cyberspace

At the bottom of the Virtu Ferries website, you’ll find that it was developed by Cyberspace Solutions Ltd. By doing a quick Google search, we can find a lot of other websites they made that have serious problems, mainly related to insecure transmission of credentials over the internet.

For example, BHS, with its insecure login form:

Same thing for C. Camilleri & Sons Ltd.:

And for Sound Machine:

The Better Regulation Unit displays a big fancy padlock next to the link where you access a supposed “Protected Area”:

…but in reality, the WordPress login form that it leads you to is no more secure than the rest of the site (so much for better regulation):

Malta Dockers Union: same problem with an insecure login form:

Malta Yachting (the one with the .mt at the end) has a less serious and more embarrassing problem. If you actually click on the link that is supposed to take you back to the Cyberspace Solutions website, you find that they can’t even spell their company name right, AND they forgot the http:// part in their link, making it relative:

Another of Cyberspace Solutions’ websites is Research Trust Malta. From the Google search results of websites developed by Cyberspace, you could already see that it had been hacked, in fact:

 

Investing in research indeed. This has since been fixed, so perhaps they are investing in better web developers instead.

This is quite impressive: all this mess has come from a single web development company. It really is true that you can make a lot of money from low quality work, so I kind of understand now why most software companies I know about just love to cut corners.

ooii

ooii.com.mt, a website that sells tickets for local events, has the same problem of accepting login information over an insecure connection.

I haven’t been able to check whether they accept credit card information in the same way, since they’ve had no upcoming events for months.

Tallinja

Similar to many airlines, Malta Public Transport doesn’t like apostrophes in surnames when you apply for a tallinja card:

In fact, they are contesting the validity of the name I was born with, that is on all my official identification documents:

Summary

This article was focused mainly on websites by Cyberspace Solutions Ltd, not because I have anything against them but because they alone have created so many websites with serious security problems, some of which verge on being illegal.

You might make a lot of money by creating quick and dirty websites, but that will soon catch up with you in terms of:

  • Damage to your reputation, threatening the continuity of your business.
  • The cost of having to deal with support (e.g. when the blog you set up gets hacked).
  • Getting sued by customers when something serious happens to the website, or by their clients when someone leaks out their personal data.
  • Legal action from authorities due to non-compliance with data protection legislation.

The Weeping Web of January 2017 (Part 2)

This is a continuation of my previous article, “The Weeping Web of January 2017 (Part 1)“.  It describes more frustrating experiences with websites in 2017, a time when websites and web developers should have supposedly reached a certain level of maturity. Some of the entries here were contributed by other people, and others are from my own experiences.

EA Origin Store

When resetting your password on the EA Origin Store, the new password you choose has a maximum length validation. In this particular case, your password cannot be longer than 16 characters.

This is an incredibly stupid practice, for two reasons. First, we should be encouraging people to use longer passwords, because that makes them harder to brute force. Secondly, any system that is properly hashing its passwords (or, even better, using a hash algorithm plus work factor) will know that the result of a hashed password is a fixed length string (regardless of original input length), so this is not subject to any maximum column length in a database.

Untangled Media

If you scroll through the pictures of the team at Untangled Media, you’ll see that the last one is broken. Ironically, it seems that that person is responsible for content.

Needless to say, broken images give a feeling of neglect that is reminiscent of the mythical broken window from The Pragmatic Programmer.

Outlyer on Eventbrite

Another thing that makes sites (and any written content, for that matter) look unprofessional is typos. If you’re sending an SMS to a friend, a typo might be acceptable. If you’re organising an event to launch a product, three typos in the same sentence don’t give a very good impression.

BRND WGN

The first thing you see on the BRND WGN website is an animation taking up the whole screen, switching around frantically like it’s on drugs:

There are only three things you can do to learn more about what the site has to offer: play a video, click on (literally) a hamburger menu, or scroll down.

While I’m not sure this can be reasonably classified as mystery meat navigation, it does no favours to the visitor who has to take additional actions to navigate the site. While the hamburger icon looks like a cutesy joke, it looks silly on what is supposed to be a professional branding website, and hides the site’s navigation behind an additional layer of indirection.

This is a real pity, because if you scroll to the bottom, the site actually does have well laid out navigation links you can use to get around the site! These should really be the first thing a visitor sees; it makes no sense that they are hidden at the bottom of the page.

I also noticed that if you click on that hand in the bottom-right, you get this creepy overlay:

The only reasonable reaction to this is:

Image credit: taken from here.

Daphne Caruana Galizia

The controversial journalist and blogger who frequently clashes with public figures would probably have a bone to pick with her webmaster if she knew that the dashboard header for her WordPress site was visible for not-logged-in users while she was logged in last week:

While this won’t let anyone into the actual administrative facilities (because a login is still requested), there’s no denying that something went horribly wrong to make all this visible, including Daphne’s own username (not shown here for security reasons).

Identity Malta

The Identity Malta website has some real problems with its HTTPS configuration. In fact, Firefox is quick to complain:

This analysis from Chrome, sent in by a friend, shows why:

Ouch. It defeats the whole point of using SSL certificates if they are not trusted. But that’s not all. Running a security scan against the site reveals the following:

Not only is the certificate chain incomplete, but the scan identified a more serious vulnerability (obfuscated here). An institution dealing with identity should be a little more up to speed with modern security requirements than this.

Another (less important) issue is with the site’s rendering. As you load the page the first time or navigate from one page to another, you’ll notice something happening during the refresh, which is pretty much this:

There’s a list of items that gets rendered into a horizontally scrolling marquee-like section:

Unfortunately, this transformation is so slow that it is noticeable, making the page load look jerky at best.

Battle.net

I personally hate ‘security’ questions, because they’re insecure (see OWASP page, engadget summary of Google study, and Wired article). Nowadays, there’s the additional trend of making them mandatory for a password reset, so if you forget the answer (or intentionally provide a bogus one), you’re screwed and have to contact support.

If you don’t know the answer to the silly question, you can use a game’s activation code (haven’t tried that, might work) or contact support. Let’s see what happens when we choose the latter route.

Eventually you end up in a form where you have to fill in the details of your problem, and have to provide a government-issued photo ID (!). If you don’t do that, your ticket gets logged anyway, but ends up in a status of “Need Info”:

The idea is that you need to attach your photo ID to the ticket. However, when you click on the link, you are asked to login:

…and that doesn’t help when the problem was to login in the first place.

It’s really a pain to have to go through all this crap when it’s usually enough to just hit a “Reset Password” button that sends you an email with a time-limited reset link. Your email is something that only you (supposedly) have access to, so it identifies you. If someone else tried to reset your password, you just ignore the email, and your account is still fine. In case your email gets compromised, you typically can use a backup email address or two-factor authentication involving a mobile device to prove it’s really you.

Security questions are bullshit; they provide a weak link in the security chain and screw up user experience. Let’s get rid of them sooner rather than later.

Malta Health Department

It is a real pity when a government department’s website loses the trust supposedly provided by HTTPS just because it uses a few silly images that are delivered over HTTP.

The Economist

Remember how you could read any premium article on The Times of Malta by just going incognito in your browser (see “The Sorry State of the Web in 2016“)? Seems The Economist has the same problem.

Article limit…

…no article limit…

Remember, client-side validation is not enough!

On a Positive Note, Mystery Meat Navigation

I’m quite happy to see that mystery meat navigation (MMN) seems to be on its way out, no doubt due to the relatively recent trend of modern webites with simple and clear navigation. I haven’t been able to find any current examples of MMN in the first five pages of Google results when searching for local web design companies, so it’s clear that the local web design industry has made great strides compared to when I wrote the original MMN article.

Summary

This is the third article in which I’ve been pointing out problems in various websites, both local and international. After so many years of web development, designs might have become prettier but lots of websites are still struggling with fundamental issues that make them look amateurish, dysfunctional or even illegal.

Here are some tips to do things properly:

  • If you’re accepting sensitive data such as credit cards of passwords as input, you have to have fully-functional HTTPS.
  • Protect yourself against SQL injection by using parameterised queries or a proper ORM.
  • Test your website. Check various kinds of inputs, links, and images. Don’t waste people’s time or piss them off.
  • Use server-side validation as well as client-side validation.
  • Ensure you have proper backup mechanisms. Shit happens.