The Archives

Internet, Mobile, Security, Software, Technology
An Open Letter to Mobile Browser Developers
March 22nd, 2011 (10 months, 3 weeks ago) by Jeff | Permalink | 1 Core Dump

If you’ve been following my Twitter account at all, you’ve probably noticed by now that I’ve become an avid mobile device (i.e. smartphone) user, and a fan of Android in particular. This isn’t just a passing phase for me, nor is this a technology fad that’s just going to fade away. Mobile technology is really taking off, and I wouldn’t be surprised if a paradigm shift won’t occur—if it hasn’t already—where more people will be using smartphones and mobile devices to access the Internet and other online services than using a full desktop or laptop. There are other contenders vying to be our one-and-only window to the digital world, like set-top boxes, digital TVs, and such, but nothing is as personal and portable as the smartphone and its bigger brother, the tablet.

That said, I’m not in the camp that believes that the Web is dead and that mobile apps are the way of the future. I’ve expressed my feelings on that here before. Apps won’t and can’t be the end-all, be-all interface to data and the mobile Web will always have a place. Thus the mobile browser is one of the most important apps a smartphone can have. That said, most browsers on smartphones are anemic, underpowered, and severely lacking in important functionality. Smartphone manufacturers and OS authors want us to believe that we can leave the laptop behind and work entirely from that wondrous miracle in our pocket, but fail to deliver the tools we need to make that dream a reality.

My case in point: client-certificate authentication. As a very brief summary, the entire industry of e-commerce rests entirely on a set of encryption technologies such as HTTPS, SSL, TLS, etc., that allow secure, private communication between a client (such as an online shopper) and a server (an online store). The server authenticates itself to the client by using a digital certificate, signed by a trusted certificate authority which has investigated and authenticated the server as a legitimate entity. The client can rest assured that the server belongs to the authenticated entity because the certificate uses strong public-key cryptography to provide a chain of trust back to the authenticating authority. Without this technology in place, we wouldn’t be able to tell legitimate businesses such as online retailers and banks from the phishing scams so prevalent on the Web. (This doesn’t always solve problems between the keyboard and the chair, of course, but it is effective as long as the wetware interface is working properly.)

But digital certificates can be used to authenticate the client as well as the server. Many businesses and governments use client certificates to authenticate users to secure systems. For example, I use a government-issued Smart Card to authenticate with my client’s servers. On this card is chip that contains my digital certificate, signed by a private certificate authority. When I authenticate with the client’s services, the private key on the card creates a digital signature which the server can authenticate against my public key, the inverse of what happens between the online shopper and the store front. Thus, I can trust the validity of the government’s certificate and know I’m connecting to their servers and no one else, and they in turn can validate that I (or the person who has my card) am who I say I am and let me in. I use a similar technology with GPF, although I import my certificates directly into the browser rather than use an external card. I created my own private certificate authority and issue client certificates to each browser I wish to use to access my admin interfaces. That way, I know only certain machines can access those portions of the site, offering a lot more security than just a simple password can provide.

This isn’t a new technology. SSL has been around almost as long as the Web itself, and it wasn’t long before the model was flipped around to authenticate clients to servers as well as servers to clients. This is a tool used by businesses every day all over the world. Every desktop browser supports client certificates because they are a standard. Any browser that doesn’t support them is likely to be overlooked or ignored in favor of browsers that do.

Yet the support for client certificates on mobile devices is appallingly absent. I know the built-in Android browser doesn’t support it, and I created an issue in Google’s official Android issue tracker to complain about it. Android supports client certs for WiFi authentication, but not in the browser, e-mail, or any other key service vital to secure business communications. Supposedly support for this functionality is going to be added in future versions of Android, but that doesn’t help me or any of the millions of current Android users until it comes time to upgrade our devices. I’ve read in various places that the iPhone supports client certs, but I’ve never been able to get any of the solutions to work with my iPod Touch (essentially an iPhone minus the annoying contract and poor service of AT&T). The only success I’ve had in this area has been with Firefox Mobile, which is pretty much a Firefox 4 release candidate smooshed and crunched down to fit on a mobile device. It’s bloated and a lot slower than Android’s built in browser and there’s no handy UI for importing certs like there is on the desktop, but if you take a sledgehammer to it and do some manual file tweaking, you can import your client and CA certs into the certificate database and use it effectively.

Seriously, guys… you want your devices and mobile OSes to be taken seriously by businesses as tools to take our work out of the office and on the road. Yet, you don’t give us the essential tools required to take advantage of this amazing freedom. Sure, you tell us “there’s an app for that”, but frankly, there isn’t. I’ve looked, and they’re not there. Apple won’t let third-party browsers compete with Safari on iOS and none of the Android add-on browsers support client certs either. Only Firefox, a desktop browser masquerading as a mobile app, comes close, and it takes a bit of technical wizardry to do something that should be a quick five second import. Someone’s got to step up to the plate and make some progress here, or no business that really understands security is going to take the mobile space seriously.
Security, Software, Technology
Cryptnos 1.0 for .NET 2.0
March 23rd, 2010 (1 year, 10 months ago) by Jeff | Permalink | Dump Core

In the ongoing spirit of releasing pointless Open Source software, I semi-proudly announce the release of Cryptnos 1.0 for Microsoft .NET 2.0.

So what is it? Cryptnos is a secure password generator. By now, I’m sure many of you have heard of various programs, especially browser plug-ins, that let you generate unique passwords for all your various online logins. They usually do this by combining the domain name of the site with a master password you supply, then run those inputs through an MD5 hash to give you a “strong” password that is unique for that site. Many of these applets also search the page you’re currently on for the login form and attempt to pre-populate the password box for you. Well, Cryptnos is kind of like that. Only it’s not.

Like these other apps, Cryptnos generates a password from your master password and from some mnemonic or “site token” that you supply. But that’s where the similarities end. First of all, Cryptnos does not live in your browser, so it can be used for any application where you need a strong password. As a corollary, the mnemonic does not have to be a domain name, although it certainly can be; it can be whatever you want it to be, so long as it is unique and it helps you remember what the password is used for. Next, Cryptnos gives you unparalleled flexibility in how your password is generated. You’re not stuck using just MD5, a broken cryptographic hash that is horribly out of date and which should no longer be used. You can select from a number of hashing algorithms, as well as how many times the hash should be applied. Crytpnos also uses Base64 rather than hexadecimal to encode the output, meaning your generated passwords can have up to 64 possible options per character instead of 16, making it stronger per character than the other guys. You can further tweak your generated password by limiting the types of characters used (for those times where a site requires you to only use letters and numbers) and the length of your password. Best of all, Cryptnos remembers all of these options for you, storing them in an encrypted state that is nearly impossible to crack. Your master password is NEVER stored, nor are your generated passwords; your passwords are generated on the fly, as you need them, and cleared from memory once the application closes.

Cryptnos originally sprang from the “Hash Text” function of WinHasher, which I used to generate passwords in a similar fashion for a long time. I quickly ran into limitations in using WinHasher this way, especially when it came to sites where I had to tweak the password after it was generated. I thought to myself, “I’ll never be able to remember all these tweaks for all these passwords. Why can’t I just rip this function out of WinHasher and wrap a program around it to let the computer do all the work for me?” And that’s exactly what I did. I’ve been using Cryptnos to generate and “store” my passwords for months now and I finally decided it was stable enough to release it to the world at large.

Right now, Cryptnos is only available for Microsoft .NET 2.0, which means by default it runs on Windows. However, I’m also working on a Google Android version, which means a pure Java implementation should be simple to extract after that. I’ve even been pursuing a PHP and/or JavaScript implementation that does everything except storing the parameter data. I’m not sure when any of these will escape from my hard drive, but anyone interested in them can drop me an e-mail and I’ll happily open a dialog.

Oh, and the name? Um, well, I wanted a better one, but that’s the only thing I could find that sounded “passwordy” that didn’t have a lot of hits on Google.
Security, Software, Technology
WinHasher 1.6
February 8th, 2010 (1 year, 12 months ago) by Jeff | Permalink | Dump Core
Wow! A non-Twitter digest post! Amazing!

This is a quickie to let you guys now I’ve just released WinHasher 1.6. This is a minor release containing a few cosmetic and minor functional changes, so there’s no need to upgrade unless the features or bug fixes listed below seem worth the effort.
- Added a progress indication message for all the console applications. Previously, these programs simply went off into lala land when you kicked them off, kind of like the original GUI version did, giving you no indication how far along things have come. Now the program displays what it’s doing (“Computing SHA-1 of…”) and then a percentage complete as it works. Once complete, it displays the resulting hash as it did before. I thought about making the progress indicator “graphical” with little periods, hyphens, or equal signs, but the percentage was a lot easier to do (and I’m lazy).
- Added a “case kludge” for comparing computed hashes against reference hashes (i.e. digests copied from a website). Typically, most sites will display hashes as a lower-case hexadecimal string, which is why I made that the default. However, I and other users have run into occasions where a download site presents the hash as upper-case hexadecimal. Unfortunately, if you paste this value into the comparison field on either the main WinHasher form or the “Send To” result dialog, the comparison will fail simply because the case does not match, even if the actual hash values do. Technically, you can tweak the command line of the “Send To” shortcut or change the output type on the main form, but either can be a pain when you know what you expect to see. So I’ve added a little bit of code that looks at what the comparison expects (i.e. “I’m looking for a lower-case hex string”) and adjusts the case of the comparison field if necessary. This means lower-case hex and Bubble Babble comparisons are forced to lower-case, while upper-case hex is forced to upper-case, no matter what case the original pasted-in string was. In the case of Base64, which includes mixed case characters, the comparison string is compared unaltered. After any case adjustment, the hash comparison occurs as previously designed.
- Fixed a bug that wasn’t displaying the icon correctly within the application itself. Oopsy.
For those who don’t know, WinHasher is a cryptographic hash generator for Microsoft .NET. It is roughly analogous to digest programs on other platforms (such as “openssl dgst” from OpenSSL) but designed for Windows and other .NET platforms. It lets you verify the integrity of downloads and determine whether changes have been made to files. It does NOT guarantee the authenticity of a file; for that, use cryptographic signatures such those produced by PGP or GnuPG. It also lets you create hashes of arbitrary text, which is handy for generating strong “passwords”, although I’m working on a different project that will do a much better job of this particular task. [Looks around shifty-eyed.]
Security, Technology
Need help: Removing old certificate revocation lists in Windows
July 9th, 2009 (2 years, 7 months ago) by Jeff | Permalink | Dump Core
I have a bit of a quandary that’s got me effectively stuck on a task at my day job. Thus far, Google and every other resource I’ve searched have been little help. In the unlikely event somebody out there that reads this blog (or at least gets the update notices via RSS, Twitter, or the other various feeds) can help me, I’m going throw this out and hope it garners some feedback.

I’ll try to keep this as short as possible. Our production Web site, built in ASP.NET and C# and running in IIS on Windows Server 2003, recently added authentication via client certificates stored on users’ smart cards. We allow users to attach their smart card certificates to their existing account, then authenticate them by verifying their certificate, looking up the user account by that certificate’s fingerprint, and loading their profile. These certificates are signed by a trusted third-party certificate authority (CA) owned by the client and every morning we download the latest certificate revocation lists (CRLs) so we can reject certificates as they are revoked by the CA. My download process is working fine and dandy, so that’s not the problem; neither is the actual import process, as I know the command line options for Microsoft’s certutil command that will import the CRLs.

My problem stems from removing the old CRLs, which so far I haven’t been able to accomplish without going into the Microsoft Management Console and clicking through the GUI. We’ve had problems with the size of the certificate store, as the CRLs tend to be very large and we have to remove the old ones before the new ones can be imported. I’ve tried the few suggestions I’ve found online that haven’t seemed to work, such as a command-line switch for certutil that’s supposed to overwrite the old CRL with the new one (it just imports the new one and leaves the old one in place). We want to automate this process into a scheduled task, so it can run early in the morning when our users aren’t on the system and without human intervention.

Here are the tools available to me:
- As previously stated, certutil (part of Microsoft’s Certificate Services package);
- Windows PowerShell;
- Anything I can throw into a .NET assembly and build an executable out of (preferably C# code);
- Good old fashioned batch files.
I’ll tell you, I’m pretty frustrated and exhausted by this task. It’s not that I can’t do the research and figure it out for myself; I have done the research, and everything I’ve read applies to certificates and not CRLs, and they’re not exactly a direct swap in usage. I’d prefer not to provide much more detail than this for security reasons.

For the time being, I’ve been manually removing the old CRLs through MMC and then running a batch script to do the import every morning as my first task. That’s working fine for now, when I’m in the office every morning, but I’ll be taking some vacation time soon that will start to cause problems. I swear, if this was OpenSSL and Apache on Linux, I’d have this solved in a heartbeat (or at least an afternoon). If you have any suggestions, please feel to post a comment or shoot me a direct e-mail at the usual address.
Software, Technology
WinHasher 1.3
June 30th, 2008 (3 years, 7 months ago) by Jeff | Permalink | Dump Core
For both of you out there who care, WinHasher has now been bumped to version 1.3. The changes are very minor, so there’s no need to upgrade unless you find the following two new features useful:
- There’s now a drop-down box to choose between hexadecimal output and Base64 (RFC 2045, although without line wrapping). I personally like using Base64 because it’s more compact than hex and more “obscure-looking”; even non-coders are familiar with hex, seeing it in error messages all the time, but are less familiar with Base64, which looks more like “random noise”. The default output is still hex, so you only need to switch modes if you really find Base64 more useful.
- There’s now a tab in the GUI to hash arbitrary text. I added this feature because there was an extension to Firefox that I used all the time to do this—which I used frequently to generate “random-looking” passwords by hashing simpler plain text and using the hash as the “real” password—but the extension hasn’t been updated in forever and is no longer working in Firefox 3. So to keep myself from getting locked out of the accounts where I used hashed passwords, I threw this feature in WinHasher. The backbone was already there, so all that needed to be added was a GUI. There’s also an encoding drop-down box that lets you change the text encoding if you so desire/need. To be honest, I don’t think it’s really necessary because I think .NET uses Unicode internally all the time, but it does have a nice side-effect: if you enter text in one encoding and change the encoding setting to something radically different (say you enter Western European Windows text but change the encoding to IBM EBCDIC Japanese), you’ll end up with a very different hash than you would have had if you used the “right” encoding. This isn’t encryption by any means as it could be easily reverse engineered if you knew what encodings were used, but it does significantly scramble things to the point that it makes it much harder to figure out exactly what you did.
I had originally started adding support for HMAC signed hashes but have abandoned that for now. If there’s anyone out there who might actually find that useful, drop me a line and I’ll revisit the code to see what I might be able to add. Downloads can be found at the first link above.
Software, Technology
WinHasher 1.2
November 30th, 2007 (4 years, 2 months ago) by Jeff | Permalink | Dump Core

I just can’t leave well enough alone. I’ve been mildly annoyed with the “hash in progress” and progress dialogs in WinHasher 1.1. The original idea was to use System.ComponentModel.BackgroundWorker to easily multi-thread very large hashes (say of CD or DVD ISOs or uncompressed video files). This had two benefits: (1) it allows the user to cancel a hash in progress and (2) gives us an opportunity to update the GUI while the hashing takes place in the background, meaning we can inform the user of the progress. Unfortunately, I couldn’t find a method right away to determine the progress of an individual hash. System.Security.Cryptography.HashAlgorithm.ComputeHash() by default takes a byte array or file stream and chugs the whole thing at once, spitting out the hash as a result. There’s no way with this method to determine how far along you are.

However, if you look at the guts of ComputeHash(), you’ll find it reads in chunks of bytes into a buffer, then calls two methods: TransformBlock() for every chunk but the last, and TransformFinalBlock() to hash the last chunk and finalize the hash. The result can then be obtained from the HashAlgorithm.Hash property. If we bypass the convenience of the single ComputeHash() method call, you can read chunks of bytes from the buffer, feed it to the Transform...() methods, and keep track of how many bytes have been read so far. Since we already know how big the file is from the start (System.IO.FileStream.Length), it’s trivial to calculate a percentage complete. Want the progress of a multi-file comparison? Sum the lengths of all files in the batch, then keep track of the total number of bytes hashed along the way.

I’ve bumped WinHasher to version 1.2. It should be available on the official site by tomorrow morning.
Software, Technology
WinHasher 1.1
November 9th, 2007 (4 years, 3 months ago) by Jeff | Permalink | Dump Core

I was downloading Fedora 8 yesterday with every intention of (eventually) upgrading Demeter, our Linux box, currently running Fedora Core 5. I say “eventually” because finding time to back everything up, install the new OS, restore all the files and third-party apps, and then spend hours debugging what went wrong is the hardest part of the whole process.

Anyhoo, I thought I’d put good ol’ WinHasher to use to verify the SHA-1 hash and make sure the download was successful. That was, after all, the primary reason I wrote the thing. But then I noticed something incredibly annoying. The DVD ISO for Fedora 8 weighs in at around 3.18GB. WinHasher has no problems hashing such a file as it hashes the file stream as it reads it, so it can hash any file of arbitrary size. But while it’s doing so, there’s absolutely no feedback to the user. In fact, if you use the right-click “Send To” shortcut, unless you go into the Windows Task Manager and check the process list, you won’t even know the thing is running. It seems to go off into la-la land until mysteriously, a minute or two later, it comes back with a mysterious pop-up box with a cryptographic hash in it.

Bad programmer! Bad!

Well, this annoyed me enough to fix it, so I’ve tweaked it now so it actually runs multi-threaded. This is ridiculously easy to do when you use the System.ComponentModel.BackgroundWorker object in .NET. You just create the object, create a few event handlers for it, and tell it to go do its thing. The hardest part is if you want it to report its progress; then you have to tweak your working code to generate a percentage complete so it has something to display. I learned this trick when I was working on Mandelbrot Madness! 2.0; I have no idea why it never occurred to me to incorporate it here. The annoying part about this addition, though, is that there’s no way to report on the progress of an individual hash. System.Security.Cryptography.HashAlgorithm doesn’t provide a way for you to know how far it’s gone, so there’s nothing to feed to BackgroundWorker.ReportProgress(). The comparison feature does, however, let you know how many of the files have been processed so far in the batch.

So if you’re one of the few brave souls who downloaded WinHasher 1.0, please grab 1.1 at the official site. It officially goes up tomorrow (a delay caused by Keenspot‘s parsing to insert the advertising codes). If you haven’t already downloaded it, why not give it a try?
Software, Technology
WinHasher 1.0 and Mandelbrot Madness! 2.0
September 26th, 2007 (4 years, 4 months ago) by Jeff | Permalink | Dump Core

I’m not sure if anyone cares, but I’ve been doing a tiny bit of dabbling in releasing Open Source software lately. Since I don’t particularly care to announce them on the GPF News (it isn’t, after all, GPF news), I’ll announce them here. For those of you who might complain that working on these has taken precious time away from the comic, fret not. The tiny bit of time I’ve been able to squeeze in here and there to work on these have been during periods when working on the comic would be impossible, so there’s no way for there to be any conflict.

The first one I’ll announce is the most recent. WinHasher is a Microsoft .NET Framework 2.0 application for generating cryptographic hashes of files. It is both a Windows GUI applet and a console (command line) program, and it operates in two possible modes. The first mode generates the hash of a single file, which you can then use to verify a download or check to see if a file has been tampered with. The second mode takes the hashes of multiple files and compares them; in this way, you can see if two or more files have the same binary contents regardless of their names, locations, and time stamps. The Windows app supports drag-and-drop functionality, and the installer lets you also build shortcuts in your Windows Explorer “Send To” context menu so you can just right-click a file and get its hash.

So why did I build this? Well, the full details are on the site, but the quick version is that I’ve grown tired of not being able to validate the hashes of downloaded files because Windows doesn’t have a built-in hashing program. Linux and the other free UNIX clones have OpenSSL; heck, even Mac OS has OpenSSL under the hood. Not Windows… of course. So instead of downloading a file on a Windows machine, copying it to the Linux box, validating the hash, and moving it back (or worse, just not even validating the hash at all and taking my chances), I hacked together this little program. Then I thought it might be useful enough to share, so I did. If you find it useful, please let me know.

For the really technically inclined out there, most of the hashes are built-in to .NET 2.0, so this was obscenely easy to implement. In fact, 2.0 has an abstract hash algorithm class (System.Security.Cryptography.HashAlgorithm) that all of the built-in hashes implement. The two non-standard hashes, Whirlpool and Tiger, were taken from the Legion of the Bouncy Castle Crypto API, which is actually .NET 1.1 based. I (rather crudely) ported these classes to be subclasses of HashAlgorithm, so they can technically be used as a drop-in replacement of any .NET 2.0 hash. I plan to add additional hashes over time, provided that (a) the original source code is free and (b) I can port it to be a HashAlgorithm subclass.

The second program to mention is actually a bit of an oldie now. (I actually released it back in June.) The Windows version of Mandelbrot Madness! is back, also in a .NET 2.0 edition. I wrote the original in Visual C++ 4.x, but have long since lost the source code. Then the Java version came into being and rapidly surpassed the Windows version, leaving it to suffer from bit rot. Both eventually languished as I lost time to work on them. Well, in December of 2005, I released the not-quite-complete-but-close-enough 4.0 version of Mandelbrot Madness JAVA!, declaring it abandoned. It always bugged me that I never went back and revisited the Visual C++ code, but without the source I was stuck.

Well, to make a long story short, my new job had me learning a new programming language: C#. That had me programing Web sites, but I knew you could also do Windows GUI apps in it as well. So somewhere down the line I got a wild hair and started the agonizing work of porting the Java code from the last version of MMJ! to C#. Actually, Java and C# are similar enough that the porting work wasn’t all that hard. Not only is MM! 2.0 now pretty much identical in functionality to MMJ! 4.0, but I introduced a number of new features that I hope to eventually port back to the Java version. While I still prefer the platform independence of Java, I’ll readily admit that the .NET version is a lot faster on Windows. I think that anyone on that platform that has actually bothered to play with the Java version (both of you) should make the switch. Anyone still using the decrepit old 1.0 version of Win32 MM! should enter the 21st century and upgrade too.

Both programs have been released under version 2 of the GPL (haven’t had time to really review version 3 yet), so the sources are also available. If you have any suggested changes, feel free to pass them along and I might incorporate them into the official builds (giving you credit, of course).