security on Much Ado About IT

Use an Authenticator App to Login to PayPal

Julian Knight — Sun, 11 Nov 2018 16:52:21 +0000

PayPal seem to think that SMS text messages are a secure two-factor authentication method. Sadly, they are greatly mistaken. This article explains why and what to do about it.

History

PayPal were early adopters of two factor authentication at a time when there was significant distrust in them as an organisation. Depending on what country you were in, you could get one of their own hardware tokens or use a Symantec VIP security token. Neither of these hardware tokens are available any more.

However, they never did adopt what the rest of the world started doing. Using “soft” tokens from a standard authenticator app on smartphones. Examples of these apps are: LastPass Authenticator, Authy, Microsoft Authenticator and Google Authenticator.

Instead, they adopted the use of SMS text messages - which were also adopted by many others due to the fact that most people were, by then, carrying mobile phones of some sort.

The Problem

Unfortunately, over the years since then, the weaknesses of SMS have been discovered. Not only can SMS text messages be intercepted relatively easily (a problem particularly in the USA) but there is now an epidemic of phone account hijacking. Phone account hijacking is where an attacker gets enough information about you that they can pretend to be you and then go on to be able to persuade your mobile phone service provider that you need a replacement SIM card. Once they have a new SIM, they hijack your account and go about changing passwords to key systems such as PayPal, Email, etc. If the second-factor for those systems uses your phone then they hijack those accounts as well.

These are really well-known issues and it is appalling that PayPal haven’t allowed people to use authenticator apps for two-factor authentication as these are a lot more secure. Especially since you can backup the authenticator details and use them on another phone in the case that yours is lost, stolen or broken. That way, you can keep control of your important accounts.

So, when you go onto PayPal and try to activate two-factor authentication, they try to force you to register a phone. Once registered, that phone will receive SMS text messages when you try to log in. You can also have PayPal phone you and you get some backup manual codes that you can type in instead. Using those alternatives isn’t especially obvious.

Please help everyone by complaining to PayPal directly and on social media so that they understand that customers no longer find this behaviour acceptable.

A Solution?

In fact, though, PayPal’s alternative token registration does still exist on their website (at least for now).

It is just *really hard to get to.

It is called Activate your PayPal Security Key.

But how do we get a mobile app that will generate the right codes to go with this page?

Solution 1 - the Symantec VIP app

The old Symantec VIP access tokens are long gone. However, they did replace it with a mobile app.

You can download the app from your phone’s app store. It will show you a “Credential ID” that you will use to plug into the “Serial number” field on the Activate your PayPal Security Key page.

Then you also provide the Security Code from the app that is currently showing, wait for the next code to show and enter that as well.

Great! Pretty simple when you know how!

There is, however, a little problem. There doesn’t appear to be any way to back up that configuration in case your phone is lost, broken or stolen. It would be FAR better if we could use on of the more standard authenticator apps such as those listed above.

Solution 2 - Using a Standard Authenticator App

So, it turns out that we can use a standard authenticator app. But it is certainly pretty painful to do it. The advantage is that some of the better authenticator apps such as LastPass Authenticator and Authy provide the ability to back up your accounts.

Here is a work around that will let you use a standard authenticator app with PayPal. It is involved and clunky but it does - currently at least - work. You will need some minimal knowledge of using a command line.

We will use a set of scripts called python-vipaccess. This will let us pretend to be a Symantec VIP hardware token. There are several versions of this application but only one seems to be maintained, the version by Dan Lenski.

In order to use this work around, you will need a computer that can run Python. So the first step is to install it. You will need v3.x of Python. How you install this will depend on your operating system. The following instructions have been tested on Linux on a Raspberry Pi. You may need to tweak things on other OS’s such as Windows.

You will also need the Python 3 version of something called pip. If using Linux, you should install pip via your package manager. The examples below use Rasbian which is derived from Debian Linux. The package manager for Debian is apt or apt-get.

Finally, the following also assumes that you have an application called git installed. If you don’t have and don’t want to install that, you can manually download the required python-vipaccess application archive from GitHub directly & unpack the archive. We will assume that you are starting on the command line from the folder immediately above the place you’ve unpacked the application (the git clone command does the equivalent).

Install the Python 3 version of pip if needed: sudo apt install python3-pip
Download an application from GitHub. git clone https://github.com/dlenski/python-vipaccess.git
cd python-vipaccess
pip3 install -r requirements.txt (takes quite a while on a Pi3. Not entirely sure you need this step or whether the next step does the same thing)
pip3 install .

The next problem is that this method of installation does not create an executable!

You have to execute using the following command:

python3 ./vipaccess/cli.py provision -p

Next, open your favoured OTP/Authenticator tool (I prefer LastPass Authenticator). Add a new account using a barcode. Now run the command:

qrencode -t ANSI256 'ZZZ'

Where ZZZ is the long URI output by the provisioning command and looks something like otpauth://totp/VIP%20Access:XXXXXXXXXXXX?issuer=Symantec&algorithm=SHA1&digits=6&period=30&secret=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY. Don’t forget to add the wrapping single quotes.

XXXXXXXXXXXX being the credential from the provisioning command and YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY being the long code you would also use with oathtool. The whole otpauth URI is given to you so you can simply copy and paste it between the single quotes in the qrencode command.

This generates a visual, 2D barcode in your terminal that you can use in your authenticator app to finish creating the new account. The account will be named “Symantec” by default.

Now go to https://www.paypal.com/cgi-bin/webscr?cmd=_activate-security-key-any

In the resulting form, “Serial Number” is the XXXXXXXXXXXX value. Then you have to enter two security codes from your authenticator app. Enter the code that is currently showing. Then wait 30 sec for the next code to show and enter that.

All being well, you should now have a new activated security key. The key should last for 3 years after which you can create a new one following the same process.

How to create secure certificates

Julian Knight — Sun, 14 Oct 2018 15:54:20 +0000

Generate certificates for Node-RED that are trusted by all modern browsers. This will let you access Node-RED (and other services) over an encrypted HTTPS link.

THIS ARTICLE IS CURRENTLY IN DRAFT - it is still being developed. Please feel free to add constructive comments and corrections below.

The problem

Argh! Why is it so hard to create and manage trusted certificates for “internal” services! While you can create your own “self-signed” certificates, all modern browsers now mark these as insecure and try to stop you from accessing them. This is wrong. Browsers should allow access to self-signed certificates if they point to a non-routable IP address (192.168.. or 10...* for example) or an invalid root domain such as *.something.local.

Also, we really probably don’t want to expose all of our internal servers to the bad, wide Internet - this is generally a really bad idea unless you are good at securing things and have the time to keep making sure they stay secure as things update.

Possible fixes

You could manually add a new (self-signed) root certificate to all devices needing access to your internal services so that your self-signed certificates are trusted - try getting that past the rest of the family!

The only other alternative is to use a trusted CA. Since I’m assuming you are doing this for testing or for use at home, I also assume that you don’t want to spend lots of money. Trusted certificates usually cost - a lot! Often US$100 per year or more.

However, there is one supplier that issues free trusted certificates. Let’s Encrypt. This is a great service for a great price. But it comes with some overheads.

It’s never simple

OK, so assuming we want to use Let’s Encrypt (LE), what issues do we now need to overcome?

Firstly, we have to have a publicly known domain address. You cannot issue a publicly trusted certificate to an IP address or non-routable domain name.

Note that certificates are generally issued to specific domain names so that www.thing.com and thing.com are different names. We don’t want to mess with all of that all the time, especially if we are doing lots of tests. So we can now use a “wildcard” certificate for *.thing.com
Next, we have to have a way for the Let’s Encrypt servers to verify that our domain name is actually ours to do something with.

By default, the LE service wants to have access back to our server in order to verify that it is ours. This would bring us back to the issue of exposing our server to the Internet, something that we prefer not to do unless we really have to.

Thankfully LE now has an alternative called DNS-01. Unfortunately, this requires our DNS (Domain Name Service) to support a particular type of secure API. For that we can use Cloudflare or any of the other DNS services listed on the LE website.
Finally, we have to renew the certificate every 3 months since that is all that Let’s Encrypt allows us to keep a certificate for. This is a pain but it does have some security benefits.

Let’s look at the details of how to do this.

1. Get a domain

We need a domain and we need it to be one that we can, at least to some degree, control. So some of the free “dynamic DNS” services probably won’t cut it. However, we can get our very own domain for a few £/$ per year so go ahead and do that. Save yourself some pain in the next bit by using Cloudflare themselves to register your domain.

Once we have a domain, we need to let it be managed by a DNS that supports the DNS-01 verification API. You might be lucky in that your domain registrar already supports that. In most cases, they won’t. So now you have to hand over control of the DNS settings to someone like Cloudflare who’s free service is plenty for what we need. Your domain registrar will tell you how to change the name servers that control your domain. Don’t worry, your registrar remains the overall controller so renewals are not an issue.

As we will be using a wildcard certificate, we don’t need to worry about setting up specific names at this point.

Also, as we will be using DNS-01 verification, we don’t need to point anything at our public IP address. Use the DNS settings to point the default “A” DNS entry at a dummy IP address like 10.10.10.10. That’s fine and it means that we won’t be leaking any information about our private network.

2a. Install a client for Let’s Encrypt

There are lots of clients for LE, see the list on their website. For this post, I’m going to use a Raspberry Pi as I have one running permanently controlling my home automation system. You could also use a NAS or any PC. Even some routers such as the ever excellent Ubiquity EdgeRouter Lite can be used.

I am going to use a 3rd-party BASH (Linux command-line) script as this is a lot simpler than the official Python based script.

From your Pi, follow the instructions to install the script. Start a remote command line using an SSH client from a convenient computer. Log in using an ID that is allowed to do administration on the Pi. Then install the script using curl https://get.acme.sh | sh. Note that I didn’t bother to become root as I need to use the certificate with a Node.JS service that isn’t run globally as root (this is best practice, don’t run things as root as that opens up additional security issues). I also ran alias acme.sh=~/.acme.sh/acme.sh manually rather than logging out and back in again to pick up the defined alias.

2b. Get the Cloudflare API details

So, we’re ready now right? Not quite. First we need somewhere to actually run the client tool that will initially get our first certificate and that will then run periodically to renew the certificate.

As we are using DNS-01 validation with Cloudflare, we need the API access details. Jump ahead in the acme.sh instructions to the part on DNS API integration since that’s what we need in order to avoid exposing our internal servers to the Internet. We need a configuration file. The instructions are in the the dnsapi folder.

Log into your Cloudflare account, go to “My Profile” under the little person icon top-right. Pick up your verified email address then scroll down to the bottom “API Keys” & click on “View” against the “Global API Key”. While you are there, turn on 2-factor authentication to protect your account and services. Keep this information safe! If someone gets hold of it, they can change your DNS and other settings.

Issue the commands export CF_Key="sdfsdfsdfljlbjkljlkjsdfoiwje" && export CF_Email="xxxx@sss.com" which temporarily puts the security information into environment variables.

2c. Get our first certificate

Now we are ready to try and get our first certificate. Run the following from your SSH command line:

acme.sh --issue --dns dns_cf -d example.com -d *.example.com

Obviously replacing the domain names with your own. The entry that starts with * gives you a wildcard certificate so that you can use this certificate with any sub-domain like www.example.com or fred.example.com.

3. Certificate renewals

As mentioned, LE certificates expire every 90 days. Thankfully, the script we just ran not only does gets us our first certificate, it sets up a script to renew the certificate every 60 days - giving some extra time for the occasional renewal failures. You can adjust the renewal in the configuration file if you really want to. You don’t have to worry about restarting this if your device reboots.

Once the script has run for the first time, go ahead and run the following so that the script itself auto-updates:

acme.sh --upgrade --auto-upgrade

Using names instead of IP addresses

New we have a certificate that we can use for any service simply by referencing that service by name.

Note, though, that you can no longer reference your services by IP address.

For example pi.example.com but not 192.168.1.20.

Using an IP address will throw an error in modern browsers.

So a slight wrinkle in our effort to get rid of browser errors since, most home servers are access via an IP address not a name. How do we fix that? We have a couple of options.

Use your router’s DHCP or DNS service to define names for local services.
Install a DNS service on a local device.
Update the hosts file on every client device.

This may work if you only have one or two laptops and nothing else but even then it is clunky. With mobile devices, it won’t be possible anyway.

Both 1 and 2 will require some configuration. What we are doing is creating names that point to local IP addresses. How you do this, depends on the router or DNS server you have.

In either case, we really want a fixed IP address to work with so that our Pi (or other device running our services) is always at the same address. All routers should have the ability to do this so look for the DHCP settings. You will need to know the MAC address of the device, it looks something like b8:27:eb:df:49:7e (you may see it with upper case letters and/or without the colons). The router’s DHCP pages will have a list of active “leases” that will show that information. You use that address, which is defined by a network interface on a device, to issue a fixed IP address via the DHCP service. Make sure that your fixed addresses don’t overlap with the range defined for DHCP to issue dynamically.

Sometimes, your DHCP server will let you define a name to go with this configuration. That’s great because you can now specify the name to include the domain that the certificate is issued to. e.g. pi.example.com.

The Ubiquiti EdgeRouter’s will let you define names manually using a Wizard called “DNS Host Names”. Some other routers may give you access to the router’s hosts file.

If you can’t do that on your router, you will need a DNS server that will let you define names to IP addresses. That’s a bit more complex and beyond the scope of this, already rather long, blog post I’m afraid.

Using your certificate

Now you have the certificate and can access your servers via names instead of IP addresses so you are ready - finally - to configure the services to use the certificates.

You can configure most TCP/IP based services to use TLS (Transport Layer Security) which is what we will mostly want our certificate for. Most people will be familiar with accessing web pages over HTTPS which is TLS applied to HTTP. But we can also use the certificate to secure communications for file transfers (FTPS or SFTP), Email (SMTPS, IMAPS, etc.).

Node-RED

Node-RED is a service built over NodeJS and ExpressJS. It creates a web server that we can secure using our certificate. The same certificate will also be used to help to secure websocket communications.

Once you’ve changed the settings below, remember to access Node-RED using the server name instead of the IP address. You will need to restart the Node-RED service.

settings.js

This file is where we configure Node-RED to use HTTPS. Note that the settings are the same as those from NodeJS so you can check out any other settings in the NodeJS documentation.

The settings.js file is found in your userDir folder which is generally ~/.node-red if installed according to the instructions on the Node-RED website. ~ is the “home” folder for the user ID running the Node-RED service.

...
module.exports = {
 ...
 const path = require('path');
 const fs = require('fs');
 ...
 https: {
 // Don't forget to adjust the paths below
 // according to your installation
 key: fs.readFileSync(
 path.join(
 '..','.acme.sh','<server_name>', '<server_name>.key'
 )
 ),
 cert: fs.readFileSync(
 path.join(
 '..','.acme.sh','<server_name>', 'fullchain.cer'
 )
 ),
 },
 ...
}

Where <server_name> is something like pi2.example.com - whatever you have defined as the name associated with the IP address.

MQTT broker Mosquitto

NOTE: This section is not complete as I’ve not managed to get this working as yet.

Many IoT systems make use of MQTT for publish and subscribe handling of data from devices. The more we embed IoT into our lives, the more important it is to secure the MQTT brokers. By enabling encrypted communications via TLS and then configuring user ID’s and strong passcodes between devices and the broker, we can help make things a lot more secure.

Mosquitto is one of the most common MQTT brokers due to its small size and high performance.

On a Linux system, Mosquitto configuration files are found in /etc/mosquitto. Try not to edit /etc/mosquitto/mosquitto.conf, instead add your own file to /etc/mosquitto/conf.d. It will be loaded automatically and will not be overridden when Mosquitto is upgraded.

/etc/mosquitto/conf.d/custom.conf

Webmin

Webmin is a really helpful remote administration tool for Linux servers. Being web-based means that you can use your certificate with it. Replace the default certificate by going to Webmin > Webmin Configuration > SSL Settings (https://<domain_name>:10000/webmin/edit_ssl.cgi?xnavigation=1).

Then change the default Private key file path with the the one generated by the acme.sh script (it ends with .key). Also change the certificate file setting to be the file fullchain.cer in the same folder.

Now restart Webmin from the main Webmin configuration page or issue the command sudo systemctl restart webmin.

No more certificate errors as long as you remember to use your server name not IP address.

Web servers

There are so many posts about configuring any of the regular web servers with certificates that I’m not going to repeat them here.

Just remember that you have all the certificate and key files that you need so you only need to make the folder available (read-only) to the user ID that runs the web server. Then to configure the appropriate files.

Router (Ubiquiti EdgeRouter)

There is a dedicated script for EdgeOS which you may wish to use for simplicity. Otherwise, you will need to remember to securely transfer the fullchain.cer and xxx.key files to the router’s filing system each time they are updated.

You can change to custom key and certificate files using the “Config Tree” service / gui.

InfluxDB and Telegraf

InfluxDB is a timeseries database that is very efficient at recording data over time. Great for sensor data. All access is, by default, over HTTP so it is possible to configure it to use HTTPS.

Telegraf is from the same vendor as InfluxDB. It can also be configured to talk to InfluxDB over HTTPS.

Grafana

NOTE: Grafana seems to want to be able to write to something - either the folder or the cert/key files - that it shouldn’t do so currently is failing. I haven’t had time to resolve this as yet.

/etc/grafana/grafana.ini

[server]
# Protocol (http, https, socket)
protocol = https

# https certs & key file
cert_file = /home/pi/.acme.sh/<server_name>/fullchain.cer
cert_key = /home/pi/.acme.sh/<server_name>/<server_name>.key

How to secure Node-RED

Julian Knight — Sun, 30 Sep 2018 13:48:14 +0000

Node-RED is increasingly used in situations that require reasonable security. Up to now, however, the information required to secure it correctly has been fragmented. This article aims to give an end-to-end outline to enable anyone to secure their installation.

THIS ARTICLE IS CURRENTLY IN DRAFT - it is still being developed. Please feel free to add constructive comments and corrections below.

I am going to attempt to describe the various options and configurations that you will need to think about in order to secure an instance of Node-RED. This is probably going to be a long article!

Please see my other articles Making Node-RED available over the Internet and Secure Home Automation Controls via a Telegram Bot for other ideas about the security of Node-RED in regard to use over the Internet and how to avoid having to worry about some of the issues dealt with here.

Warning and disclaimer

This is my best view of securing Node-RED. I’ve not been a professional developer in a long time and I am not a professional security analyst (I’m a IT technology and information security manager).

So you must not assume that this article covers every issue. You must also not assume, even if you follow every best practice, that an instance of Node-RED will be “Secure”. It may not be for many reasons.

Get your system and its infrastructure tested to destruction by professionals.

Hopefully though, this article will at least let you see the issues and have a reasonable go at making your instance of Node-RED a little more secure.

Terminology

A few words and phrases that will be used along with the least technical descriptions that I can come up with.

Term	Meaning
Encryption	Changing human readable information into something that requires a special key before it can be understood.
Authentication	Providing a secured identifier to a system to prove that the person accessing the system is who they claim to be.
Authorisation	Controlling what information a user of a system is allowed to see and what actions they are allowed to take.
TLS	A defined protocol for securing connections between systems and applications. In basic use, it provides a minimum level of authentication of a server (via a certificate chain of trust) and facilitates encrypted communications with that server.It also has additional mechanisms that will also provide a minimum level of trust of the client application. However, this is rarely used in Internet web applications.TLS may be used to secure many different application and system interactions, not just between a browser and a server.
HTTP(S)	The main web protocol that lets browsers get human readable information from web servers. HTTPS is HTTP secured with TLS (used to also allow a protocol called SSL but that is deprecated as insecure). Ideally, every connection to a server from a browser should be over HTTPS since the use of HTTP allows some pretty bad things to happen.

The basic architecture of Node-RED

To help us understand what needs to be secured, here is the basic technical architecture of Node-RED. From the outside in. This is only one way to view the architecture of course, I’ve tried to keep things as simple as possible.

Your flows, Dashboard and other pages served by Node-RED

This is the “code” that you (or your users/administrators) have put together.

Node-RED is a general purpose tool and so is capable of creating web pages and various other types of connections such as websockets, TCP/UDP connections and much more.

Anything that is created at this level either must be secured by Node-RED’s settings or by your code.
The Node-RED runtime API

This is the bit of magic that makes everything work. At some point, this will be independent to the administration side but at the moment (~ v0.19) it isn’t.
The Node-RED Administration user interface

This is a web application (web page plus websocket connections) that lets you build your own applications using Node-RED. It uses various 3rd-party libraries to do some of the heavy lifting (D3, JQuery, etc.)
The Node-RED core and contributed nodes

Here is all of the clever custom code, generally tucked out of the way so you don’t need to worry about it.
ExpressJS

ExpressJS is a library for NodeJS that does the heavy lifting of providing a web server.
NodeJS

NodeJS is a collection of JavaScript and C code that lets people build application servers across different operating systems. It lets people use JavaScript (typically a browser language) to create their server applications.
Operating System

Apart from the hardware, we are now at the bottom of the architecture.

No point in securing everything else unless you have secured things at this level.

In order to secure Node-RED, we have to pay some attention to all of these layers. Thankfully, the guys to created Node-RED have thought about many of the details and made it at least somewhat easier to provide a basic level of security.

Settings that you need to think about

Other considerations

NodeJS and package vulnerabilities

As Node-RED itself needs to have backwards compatibility with older versions of NodeJS, it may be forced to use packages (AKA modules or libraries) that are now out-of-date. Similarly, nodes that you rely on may not get updated as regularly as needed to stay ahead of vulnerabilities.

NodeJS itself is very rapidly changing and unless you are updating it regularly (e.g. weekly) it may also have outstanding vulnerabilities.

To mitigate these issues, you need to:

Update NodeJS weekly or daily in sensitive installations. You will also want a set of regression tests - test that are run after every update - if you want users to be able to rely on rapid update cycles.
npm itself may have vulnerabilities and may need to be updated out of cycle from NodeJS.
Regularly run npm outdated and npm audit on both the location you install Node-RED (global by default) and the location where you install contributed nodes. Update nodes regularly or consider the impact of nodes that have dependencies failing audits. Note that npm audit is only available on newer versions of npm.

Issues and limitations

Specifics

References

Node-RED Official documentation on security
Making Node-RED available over the Internet
Secure Home Automation Controls via a Telegram Bot
Why should we use HTTPS?
1. Google’s take
2. Cloudflare’s take
3. The US Government’s take
4. A leading security experts take (Troy Hunt)

Presentation: Security and Governance in the Cloud

Julian Knight — Mon, 28 Nov 2016 12:54:25 +0000

Here is a presentation that I did recently for NHS CIO’s and CCIO’s. It is all about how NHS England has followed a journey to cloud services and the IT Security & Information Governance issues we had to deal with along the way. It tries to also show other NHS organisations how they might work towards similar aims.

Cloudflare Now Active

Julian Knight — Fri, 17 Oct 2014 08:50:05 +0000

After the recent high-profile vulnerabilities, I decided to turn on the free version of CloudFlare for this domain.

CloudFlare provides a reverse proxy service that sits in front of your domain. It will serve content where it can on your behalf (caching), optimise content where it can (e.g. minimising JavaScript, HTML, CSS, etc.). But even more important from my perspective is their ability to protect against a number of vulnerabilities.

The most obvious protection – because this is where CloudFlare started – is DDOS protection. DDOS is a way of throwing very large numbers of requests at your domain, preventing legitimate access. But CloudFlare also now provide protection against other threats and it is interesting to look at the dashboard and seeing a bunch of threats being filtered out every few days.

A recent add-on, especially to the free service, is the ability for CloudFlare to provide SSL security for free. This means that your whole site can present as HTTPS (encrypted HTTP) & you can even enforce this so that visitors cannot connect without encryption. This is easily done without the hassle normally associated with creating and maintaining SSL security.

Kudos to CloudFlare for providing this excellent service and for providing a useful free version. I’m happy to recommend it to everyone who runs a web site or service.

Update 2018-05-04

I still use CloudFlare for most of my published endpoints.

However, this blog has now been moved from self-hosted WordPress to a Hugo-based site hosted by Netlify. Netlify allows me to set all manner of security headers and has inbuilt support for Let’s Encrypt certificates.

So Cloudflare protection is no longer required for this blog.

Stay Secure! The Latest Recommendations for IT Security

Julian Knight — Tue, 27 Aug 2013 21:07:14 +0000

Individuals and enterprises do not understand the value of their Information nor how to protect it. This article attempts to reveal simple and practical ways to protect IT assets and outlines some of the latest thinking and tools from industry experts.

IT Security changes over time and it is important to stay abreast. New threats are appearing all the time and so threat management also needs to change.

Here are some tips and pointers to the current thinking in IT Security.

Back in February of this year (2013), the Centre for Strategic and International Studies (CSIS) in the USA published a short but to the point paper on how to successfully combat the majority of current cyber security threats. The paper gives an excellent background to the latest threats without getting too technical. But the great thing is the 4 steps that they give to combating the majority of current threats.

These are summarised as:

<li>
<div dir="ltr" data-font-name="g_font_p0_1" data-canvas-width="152.32256276321408">
<em>Patch operating system vulnerabilities, for the same reasons discussed above</em>.
</div>
</li>
<li>
<div dir="ltr" data-font-name="g_font_p0_1" data-canvas-width="613.1027311220175">
<em>Minimize the number of users with administrative privileges, the highest level of authority to make changes or undertake actions on a network</em>.<br /> Users with administrative privileges are the goldmine for the bad guys. They are the easy back door into the heart of your enterprise systems.
</div>
</li>

Update on FreeOTFE

Julian Knight — Wed, 05 Mar 2008 15:19:00 +0000

Thought I would add a quick update on using FreeOTFE under Windows and PocketPC.

I tried it under Windows on a different PC and it does indeed work OK though it is nowhere near as polished as TrueCrypt. I’ve also tried again a few times on a PocketPC with limited success and I think I know what is happening. Firstly, you must install FreeOTFE for PPC into system memory and not on a storage card – not terribly surprising really. However, you do not seem to be able to use a secure volume from a storage card either very reliably (I tried on a T-Mobile MDA Compact III). I did have some success creating a small volume (approx. 2MB) in main memory, it did load eventually. Sorry to say that this is unworkable and I’ll be sticking to Keepass and Tombo on PPC with TrueCrypt on Windows and Linux. It is worth noting in passing that TrueCrypt for Linux now has a native UI.

Keeping information secure but accessible across platforms

Julian Knight — Mon, 21 Jan 2008 21:20:00 +0000

One of the issues with Linux is that I can’t use it under all circumstances. In particular I usually have to work with Windows at work. So I need cross-platform tools, especially now that I also make extensive use of a smartphone/PDA. So here is a timely post – with the number of people in UK government departments carelessly loosing private or secret information, how do we keep this stuff secure while still being accessible from different platforms? Oh, and we don’t really want to pay out money for the privilege if we don’t have to! Well, I’ve looked at 3 tools that will do everything we need and they wont cost a penny. First up is Keepass.

Keepass is a tool for storing passwords, primarily aimed at web site use but it serves perfectly well for storing any password type information and I use it for storing license numbers, router passwords, etc.

Keepass runs on Windows as the main platform and that version has some really nice features such as a macro language for logging in to web sites and the ability to run local applications. This version does not need to be installed so it will run from a pen drive as well.

There is also a version for Windows Mobile/PocketPC, just synchronise the database file to keep it in step with the desktop.

Then there is [KeepassX][1] which runs under Linux and Mac OS. It is not quite as feature rich as the Windows version but it still does nicely. The remaining two applications all work with virtual (or real) disk partitions by encrypting them and allowing you to access them like ordinary disks. [TrueCrypt][2] comes first. This is supported on Windows and Linux (a Mac version is due out in Jan 2008). It is pretty easy to use under Windows. Linux only has a GUI for Gnome but you can also use [ScramDisk for Linux][3] as a GUI under KDE. TrueCrypt does not need to be installed so runs nicely from a pen drive. Sadly, there is no mobile version. [FreeOTFE][4] is notable in that it supports Windows, Windows Mobile/PocketPC and Linux. The Linux support is via LUKS which is a standardised, well supported loopback encryption application ([how to create a loopback secure container][5]). I’ve not tried FreeOTFE yet, but it does seem to have a good range of capabilities. Under Windows, it also works with the [Secure Tray utility][6] (also by the same author, Sarah Dean) which allows for the automatic running of applications when a volume is mounted. I am sure that I’ll be trying this out at some point.

Update 2008-01-24: Sadly, the PDA version of FreeOTFE cannot mount Linux volumes so there is still not a true cross-platform solution. The best I can do is to set up TrueCrypt for PC/Linux (easier than FreeOTFE) and FreeOTFE for PC/PDA with an automated sync between the two.

Update 2008-01-29: I’ve now actually tried FreeOTFE on a PC and on a WM5 device and I’m afraid that they tend to hang almost continuously so this is not really an option I can recommend. It’s a shame as it looks great on paper. There is a real missed opportunity here, especially if the PDA version were to support Linux volumes. Update 2008-07-10: An additional plus for FreeOTFE is that it does not require admin access (under Windows) to run. I suspect that this will get more and more important as more organisations lock down their PC’s but continue to fail to provide sufficient support and capabilities. Between TrueCrypt and FreeOTFE, I’d say the former is easier to use as it hides much of the gory bits away but FreeOTFE has the features and cross-platform support. I may well find use for both.

Given the problems with FreeOTFE that I experienced. I’ll carry on using TrueCrypt on Windows and Linux and [Tombo][7] on the PDA and Windows with manual copies between the two – drat, too much reliance on Windows. [1]: http://www.keepassx.org/ [2]: http://www.truecrypt.org/ [3]: http://sd4l.sourceforge.net/ [4]: http://www.freeotfe.org/ [5]: http://www.mayrhofer.eu.org/Default.aspx?pageindex=6&pageid=34 [6]: http://www.sdean12.org/SecureTrayUtil.htm [7]: http://tombo.sourceforge.jp/En/