Posts tagged with "cryptography"


SHA-3

Icon from the Tango Desktop Project

In 2007, it seemed all we read about in crypto circles were successful attacks against the MD5 and SHA family of hashing algorithms. Well after a six year contest, NIST is about ready to announce a suitable replacement to be dubbed SHA-3.

Interestingly, Bruce Schneier isn't so enthusiastic:

It's not that the new hash functions aren't any good, it's that we don't really need one. [..] We didn't know [in 2006] how long the various SHA-2 variants would remain secure. But it's 2012, and SHA-512 is still looking good.

That said, Skein and it's Threefish block cipher look really intriguing. I eschewed Rijndael/AES and use Twofish for all my personal crypto.


Are sites storing your passwords securely?

There have been so many password "hacking" stories lately, I thought I'd write this post so I can refer back to it. For added security, I've included the above image of Makise Kurisu, the scientist in my anime harem.

Covering my behind

Crypto is an exact science, so before I go any further I will make these clear.

  • When I say random, technically I mean pseudorandom. Algorithms are deterministic, and computer order and logic can't strictly speaking produce "true" randomness. Contemporary algorithms are an order of magnitude better than the BASIC RND() function of yore though.

  • When I say impossible and one way, I mean practically speaking. Our current algorithms would take the birth and death of several universes to brute force with current hardware, but that doesn't mean it's impossible. Just very very very very improbable!

How passwords are supposed to be stored

When you create an account with a well designed, secure website, your chosen password is not stored anywhere. Instead, your password is put through a one way cryptographic hashing algorithm which converts it to random gibberish, along with some salt or random information only the web server knows.

When you attempt to log into your site, the password you give is hashed and compared to the hash on file. If they're the same the server knows you have the right password.

It's a proven, tested technique and it works... provided everything is implemented properly. No doubt you've seen plenty of news stories suggesting sound security is harder than coming up with some snappy alliteration on a blog post.

Why go to the trouble?

Rather than storing a hash of a password, you could simply store the password and compare it when someone logs in. It's simpler, and a worryingly large number sites still do this.

The problem is, if the database is broken into, the malicious hacker has access to all your customer's passwords. People like conserving energy (politically correct way of saying lazy!), and are probably using those same passwords for all sorts of stuff including their banking sites, email, social networks and so on. You can see what a disaster this could be!

If you store them as hashes, all anyone ever sees is random gibberish... even the site owner!

How to tell

Short of asking the site administrator, there are two main tells that a site is storing your passwords instead of a hash:

  • They're able to provide you with your password. This could happen when you first create your account and they send you a welcome email, or if you've said you've forgotten your password. A secure site should always direct you to a page to reset it, because they don't know your password either.

  • Hashes take any password length and adjust them to a uniform size (such as 128 bits). Not always, but often if a site puts a limit on your password length, it's because they're storing it as plaintext in their database.

There may have been (bad) excuses for these practices in the past, but not any more. If a site you access does either of these, it's time to question how important they are and whether they're worth risking your data and security over. Blunt, but true.

If you suspect a site you access is storing your password in plain text and you have no choice but to use them, complain, and make sure you pick something random and unique to that one site. If/when they get broken into, you'll be glad you did.


Installing TrueCrypt on x86 or x84 Fedora

TrueCrypt

Because of some licencing issues (that from a pragmatic point of view don't really bother me) TrueCrypt for Linux isn't usually available from package managers unless you add third party repositories. I really hate that word. I prefer installing it manually, and the installer lets me choose where to put it.

The quick way

1. Go to the TrueCrypt downloads page and choose the Linux install for your system architecture.

2. Do the usual tar extract, and execute the resulting file much as you would an installer. For example, the latest (at the time of this post) for 64 bit CPUs:

% tar xzvf truecrypt-6.3a-linux-x64.tar.gz
% ./truecrypt-6.3a-setup-x64

3. Choose option 1 when the installer prompts, then hit [Page Down] a few times and enter "yes" to accept the licence agreement.

4. Fedora places TrueCrypt in the Accessories groups in Xfce and Gnome, I assume it would for KDE and LXDE too.

The more custom way

If you prefer, in step 3 if you choose option 2, TrueCrypt extracts itself into /tmp so you can place them where you prefer. For example, because of my FreeBSD history I like having resources I install to be run from /usr/local, so once I've extracted them I move them to where I want. Done and done :).

And the best part of all...

Once you have TrueCrypt installed, you can use it to hide whatever you want from overzealous and legally dubious Australian customs officials (Aussie customs can now search laptops)!

Then again, if you're running Fedora or another free/open source operating system I doubt they'd even be able to figure out how to use it let alone perform a constitutionally illegal search.

Then you can use it to hide everything from overzealous legally dubious Australian customs officials.


Bruce Schneier facts, again!

Bruce Schneier

Back in 2006 I posted some of my favourite Bruce Schneier facts. Here we are in 2010 and I still read ones that make me laugh out loud!

  • The sum of the ASCII values of the characters in Bruce Schneier's passwords is always a prime number. Their product is too.

  • Bruce Schneier; brain the size of a planet.... Reduced to writing about encryption for mortals; gets very depressed.

  • Bruce Schneier can read and understand Perl programs.

  • There are no prime numbers, only numbers Bruce Schneier lets you factorise.

  • Bruce Schneier knows a deterministic algorithm to generate non-pseudo random numbers without need of an entrophy source.

Good encrypted disk images on Mac OS X

There are many options for those using recent versions Mac OS X to encrypt files, one of which is to create an encrypted virtual disk image which has the advantage of being portable across different computers and is simple to backup. While I am still a fan of TrueCrypt because it's disk images can be opened on multiple OSs (subject for a future post), for Mac specific files I find using hdiutil is the easiest way to go and generally has better performance.

Why not use Disk Image.app?

While you can use Disk Image.app to create encrypted disk images, for some reason Apple refuses to allow you to paste passphrases. I'm sorry, but I don't consider manually typing 256 character pseudo-random gibberish passphrases with punctuation, letters and numbers to be very practical! If anything by not allowing people to paste passwords Apple are discouraging people from using really solid passphrases.

Create a good passphrase

I like to copy a huge long list of high quality pseudo-random passwords from GRC's Perfect Passwords page into a text file, then use one of them along with a phrase I have memorised for the final passphrase. That way, even if someone gets a hold of that file, they can't derive my passphrase from its contents. Goes by the security philosophy of something I have, and something I know.

Create the disk image

Fire up your Terminal.app then enter the following:

hdiutil create -size 10g -type SPARSE -fs HFS+J \
-encryption AES-256 -stdinpass -volName LABEL-NAME \
FILE-NAME.sparseimage
-size 10g
Potential maximum file size in gigabytes
-type SPARSE
Dynamically expand the image as you fill it
-fs HFS+J
The initial filesystem, Mac HFS+ Journaled in this case
-encryption AES-256
Far stronger of two encryption options.
AES-128 may be faster on slower hardware, but is obviously less secure
-stdinpass
Require passwords to be entered in standard input
-volName LABEL-NAME
Name you choose that will appear in the Finder and /Volumes
FILE-NAME.sparseimage
Name you want for your disk image file

Accessing

If you view your Home folder you'll see your new disk image. Problem is, like I said with Disk Utility.app above if you double click you can't paste your passphrase in.

To access, just fire up Terminal.app and use the attach keyword. When it prompts you for your passphrase, you can paste your string of high quality pseudo-random gibberish then enter the part you remembered:

hdiutil attach FILE-NAME.sparseimage

You unmount the disk image in the same way you eject USB keys and optical discs in the Finder.

Other tips

If you create disk images that are smaller than 4.5GiB, you can burn your encrypted image to a DVD which makes it a cinch to backup! Also with this level of encryption the easiest way for people to access to your data is social engineering attacks: don't let yourself down by using a crappy password and obviously don't share it with anyone except perhaps your cat. No wait, cats are too smart.