Archive for Jul, 2009

Good Password Hygiene

Jul 28, 2009 at 10:57 · Filed under Security, Technology ·Tagged , , ,

In a hypothetically perfect world, we’d be able to remember infinite numbers of passwords. However, for most people that’s not possible. Instead we have to find a way to make best use of that limited memory. Here’s how:

  • Do not use passwords that are easy to guess, e.g anything directly related to you, like your name or names of family/friends/pets/etc; or date of birth; or favourite colour,band,etc..
  • Ideally, use a longish random string as your password, of at least 10 characters (but longer is better).
  • The same applies for password-recovery questions, which often ask for information that is in the public domain (e.g. mother’s maiden name, date of birth). Do not provide real answers! Instead just make something up, or use another random string if possible.
  • Do not re-use passwords across different websites, unless you truly do not care about what is on those sites, and what they can do in your name with that password.
  • Do not be afraid to write them down if you can store them securely. E.g. if your home is reasonably secure, it’s fine to store most passwords on paper there. This goes against advice from many well-meaning, but utterly-wrong “experts”.
  • If you trust that a computer or device is sufficiently secure, it’s perfectly fine to store passwords on it, e.g. in a text-file. Also, many programmes support saving passwords and if you trust those programmes then it’s perfectly OK to use those features.
  • Consider using disk-encryption products like PGPDisk, TrueCrypt, BitLocker or the built-in capabilities of many Linux/Unix distributions (some of which offer this at install time) to protect your data with a master key. This is particularly recommended for laptops.
  • Any computer running Microsoft Windows likely can not be considered secure and should not trusted with more sensitive information. Portable devices should not be considered secure, unless their contents are known to be encrypted, and they automatically lock themselves after a small period of unuse (i.e. don’t trust your phone too much for storing sensitive data).

Basically, in an ideal world, all your day-to-day passwords for your various, online accounts should be unguessable, random strings;  you’d never have to remember any of them; you would just, at certain times, have to enter a master pass-phrase (which should be unguessable, but still memorable and much longer than a password) without which the passwords would effectively not be accessible.

Remember, security is a compromise between convenience and consequence. The ideal level of compromise will differ between different people, and between different situations. E.g., obviously, it’s probably a good idea to tolerate a good bit of inconvenience with your online banking login details and commit these solely to memory. If you have too many accounts to memorise the details, then store them very securely, e.g. buy a strong box or small safe, and obscure which details belong to what accounts – hopefully this buys enough time to contact banks and have the details changed if your house is burgled and the box stolen.

Common sense goes a long way. Unfortunately the “experts” you sometimes hear from don’t always have it.

Comments (2)

Sharing DNS caches Considered Harmful

Jul 15, 2009 at 15:14 · Filed under Technology ·Tagged , , , , , , , ,

Eircom have been having problems with internet connectivity. It’s hard to get information about exactly what they’re seeing, but there seem to be 2 aspects to it:

  1. Eircom are getting hit with a lot of packets
  2. Customers have sometimes been directed to strange sites by Eircom’s DNS servers

Justin Mason has a good overview of the news coverage. There some points of his worth correcting though:

I.e. DDoS levels of incoming DNS packets are consistent with a poisoning attack on up-to-date DNS servers, which randomise QID.

The moral of the story here is that using recursive, caching DNS servers that are shared on any significant scale, like ISP nameservers or (even worse) OpenDNS, is just unhygienic. They’re just fundamentally flawed in todays internet environment, as they’re juicy targets for poisoning, until DNSSec is widely deployed. When finally DNSSec is deployed, shared, recursive nameservers remain a bad idea as they terminate the chain of the trust – the connection between the NS and client can still be spoofed.

In short:

  • Technical users and systems admins should install local, recursive nameservers. Preferably on a per-system basis.
  • Operating system vendors should provide easily-installed recursive nameservers and should consider installing and configuring their use by default. (Fedora provides a convenient ‘caching-nameserver’ package, and also a new dnssec-conf package with F11, though not enabled by default).
  • Consumer router vendors already ship with recursive servers, but tend to forward queries to the ISP – they should stop doing that and just provide full recursive service (hosts already do caching of lookup results anyway).

Widely shared, recursive nameservers are a major security risk and really should be considered an anachronism. It’s time to start gettting rid of them…

Comments (11)

Mail-Followup-To Considered Harmful

Jul 8, 2009 at 15:33 · Filed under Technology ·Tagged , , , , ,

Dear Interwebs,

If you happen to have responsibility for some software that processes mail, please take the time to check the following:

  • That your software always errs on the side of preserving the Reply-To header, when passing on email. E.g. email list software in particular should not overwrite existing Reply-To headers, even if a list is configured to set a default Reply-To.
  • That your software can process Reply-To headers that have multiple email addresses.
  • That your software provides adequate, interactive cues to its user when they reply to an email, so as to discern what the user wants, in the context of what the sender prefers (so far as that is known).
  • If your software supports various weird, non-standard headers, like Mail-Followup-To, Mail-Copies-To, Mail-Replies-To, etc. deprecate and remove this support. No amount of extra headers can obviate the need for the cues in the previous point – all they do is make the situation worse overall.
  • If your software must support these headers, do not let such support cause the standard and well-supported Reply-To header to be automatically ignored.

If you’re a user of software that honours Mail-Followup-To and/or has buggy Reply-To behaviour, please file bugs and/or send them patches.

So why are Mail-Followup-To et al harmful? The answer is that they increase the number of ways that the wishes of the sender, the respondent and the state of the email may interact. What was already a tricky and murky area is made even murkier when you try add new ways to indicate the desired reply-path. E.g. witness Thunderbird’s help on MFT, or Mutt’s help on Mailing lists. I defy anyone to be able to keep all the rules of their MUA behaves in the presence of the various combinations of Reply-To, From, To, Cc, Mail-Followup-To and Mail-Reply-to in their head. For the few who can, I defy them to keep track of how their MUAs support interacts with the support in other MUAs.

Further, Mail-Followup-To has never been  standardised. The header is described in  DJB’s Mail-Followup-To and the dead IETF DRUMS draft. Both specs effectively say that the absence of MFT when a client does a “followup” reply should continue to go to the union of the From address (From == From or Reply-To), To and the Cc. However, these descriptions carry little authority. Unfortunately Mutt, one popular MUA, behaves differently when in list-reply mode and does not fallback to (From|Reply-To)+To+Cc in the absence of MFT – at least when I last investigated. This means Mutt basically does not inter-operate with other MUAs, when it comes to the standards-track means of indicating Reply preferences.

Before we had the problem of trying to get a few cases of bugs in broken Reply-To handling fixed (e.g. lists that blindly over-write Reply-To) + the UI design issues of figuring out where a user intends replies to go, without annoying them. Now we’ve added the problems of fractured interoperability with new same-but-different headers + the problems of bugs and deviations in the implementations of said new same-but-different headers.

Mail-Followup-To == more mess == even more brokenness.

See also: Archived DRUMS discussion on Mail-Followup-To.

Comments (2)

EuroIX Looking To Sponsor Quagga Development

Jul 6, 2009 at 16:53 · Filed under Quagga, Technology ·Tagged , , , ,

Euro-IX is looking to sponsor Quagga development. This was announced by Nick Hilliard in a post to the quagga-dev list. This is really great to see and I commend Euro-IX for providing these resources for Quagga.

Leave a Comment

Microblogging / Social Networking updates

Jul 6, 2009 at 16:45 · Filed under Technology, Uncategorized ·Tagged , , , , , , , , ,

Micro-blogging, like Twitter is the latest rage. Not understanding why I, of course, have decided to try it out. My Twitter account is pauljakma, and my Identi.ca account is paulj.

Identi.ca is quite handy as it has the ability to connect to Twitter and Facebook, and update your status there as/when you update your status on it. I am also using gwibber, a Linux/GNOME micro-blogging client which can connect to several social-network and micro-blogging sites, including all the above. The resulting flow of messages is best described here. I have also installed mobidentica, a light-weight Laconica/Identica client for Symbian S60, onto my Nokia E51, for on the go micro-blogging but I haven’t really used it in anger yet.

So basically, I can update my status on Twitter, Identi.ca and Facebook all in one place. E.g. from Gwibber, if I’m using my desktop; or via Identi.ca if I have access to a browser; or mobidentica via my phone. Identi.ca can also synchronise with services that use the Jabber IM protocol, like Google Talk and Nokia’s Ovi chat client.

The one downside is that there may be a bit of an impedance mismatch in audience between different micro-blogging/social-network sites. E.g. my Twitters/’dents tend to be more techy, which could seem strange to various Facebook family and friends who are not techies.. It’d be nice if Identi.ca had a fine-grained, in-line way to control which ‘dents were sent to Facebook.

Leave a Comment