Cryptnos

About Cryptnos


Last updated June 26th, 2015

Cryptnos is a multi-platform, Open Source application for generating strong, pseudo-random passwords using cryptographic hashes. It combines a unique “site token” such as a website domain name with a master password and runs this data through a cryptographic hash algorithm to produce a password that is unique, lengthy, seemingly random yet completely repeatable. Unlike similar products, however, it is exceedingly flexible. It is not a browser plugin, so it can be used with other applications outside the Web. It provides unparalleled versatility by letting you specify the cryptographic hash to use, how many iterations of the hash to perform, what characters to include, and how long the final password should be. Best of all, it is exceedingly secure. Your master and generated passwords are NEVER stored, and the parameters to recreate your passwords are stored in an encrypted form.

Cryptnos is currently available for Microsoft Windows via the .NET Framework 2.0, as well as for Google Android powered devices. A version for pure Java is under development, as well as an HTML/JavaScript online version that should work with any browser.

Features

  • Generates strong, pseudo-random yet repeatable “passwords” using a variety of cryptographic hash algorithms
  • Supported hashing algorithms: MD5, SHA-1, SHA-256, SHA-384, SHA-512, RIPEMD-160, Whirlpool (2003 revision), and Tiger (1995 original, not “Tiger2”)
  • Combines site domain or mnemonic (we call it the “site token”) with the user’s “secret token” to produce a unique password for every site
  • Further modify the generated password for character class or length constraints (e.g. limit to only alphanumerics and a maximum of 12 characters)
  • Stores password generating parameters securely using cryptographic hashes and strong AES-256 encryption (exact method varies by platform)
  • Cross-platform import/export mechanism allows parameters to be copied from one instance of Cryptnos on one machine to another instance on another machine, strongly encrypting the export file using AES-256 (not available with the online version)
  • Integrated help

History

Shortly after I (Jeff) created the WinHasher application for generating cryptographic hashes of files on Windows, I came up with many ideas on how to tweak it. In addition to generating hashes for a file that could be used, say, to verify a download from the Internet, I also added a simple interface for comparing two or more files to see if their contents were identical. Almost as an afterthought, I added the ability to hash arbitrary text; the user could select a hashing algorithm and a character encoding then enter whatever text they wanted into a field, and WinHasher would generate the accompanying hash.

The idea behind the hash text feature of WinHasher was mostly to generate secure, pseudo-random passwords for Internet websites. By combining a unique “token” to identify the site (say, “gmail.com”) with a “secret” token that only I would know and then passing both through a cryptographic hash, a strong random-looking password could be generated that would be unique for the given site, difficult to reverse engineer, and easy to regenerate given the same inputs. While there are already existing utilities for this purpose, including ones that plug directly into various Internet browsers, I wanted to design this myself, in part for the intellectual and programming challenge and in part in the spirit of “trust no one”, eliminating reliance on external utilities that could disappear who knows when. By building my own utility, I knew it would exist as long as I deemed necessary. This password-generating “side-effect” of WinHasher quickly became the feature of the program that I used the most. That said, it was not ideally designed for that purpose.

In order to prevent the generated passwords from being too predictable, I had to make sure to include a “secret” portion of the plain text to “salt” the result with unknown data. Without such a salt, it would always be theoretically possible that someone could use a “rainbow table” style attack and compare the generated hash to other outputs to discover the plain text. That said, the full input into WinHasher’s Hash Text function—the unique site “token” to identify the site plus the “secret”—had to be entered in visible plain text, allowing random passers-by to read the full input over the user’s shoulder. In addition, I quickly found that many sites place restrictions on the contents of user passwords, including length and character class restrictions. If a site only permitted alphanumerics in a password and limited its length to twelve characters, the raw output of a SHA-1 hash in Base64 couldn’t be used; it had to be further edited to remove unwanted characters. I ended up resorting to saving such generated and tweaked passwords in a text file, externally encrypted with GnuPG, to keep track of them. While the passwords themselves were strong and difficult to brute-force, the encrypted text file quickly became a bottleneck and a security risk in and of itself.

What I needed was something that performed all these tasks for me automatically:

  1. Separate the site token and secret from each other and mask the secret with the usual password-text masking (i.e. eliminate over-the-shoulder snooping);
  2. Include the option to limit what character classes are generated (i.e. strip out non-alphanumerics if needed, etc.);
  3. Include the option to limit the number of characters in the generated password;
  4. Store all these parameters—minus the secret, which should never be saved—in a secure fashion so they can be automatically populated when the site token is selected from a list (i.e., I don’t have to manually keep track of which options I had to tweak).

After reviewing the requirements, I felt that there were more changes than I felt comfortable shoehorning into WinHasher to make it do something beyond its core purpose. A new application was warranted. Clearly there would be a bit of overlap and some code could be reused, but the core functionality would be essentially new. With this in mind, I began slinging around some code and the .NET version of Cryptnos was eventually born.

Not long after the original incarnation of Cryptnos became stable, I managed to acquire a Motorola Droid smartphone running Google’s Android operating system. I wanted to be able to use the passwords generated by Cryptnos while on the go, so naturally I needed a version of the program that I could access from the phone. Development could progress in one of two directions: an online version written in PHP and/or JavaScript that I could access via the Android browser, or a native Android application written in Java and executed directly on the device. I began exploring both options and found porting the .NET code to these platforms surprisingly straightforward. Of course, writing a version for Android meant that it would be relatively simple to port that to pure Java as well, so I might as well add that as a target. As of this writing, the .NET, Android, and Online versions of Cryptnos are all live and in the wild, with the Java version in active development. Input on the development of these projects is heartily encouraged.