Archive for the ‘Projects’ Category

eduLogon has been open-sourced

Saturday, April 24th, 2010

Well, it was a good ride, but I’ve conceded that the time has come to strip eduLogon of its commercial licensing code/incumberances, and post the rest of the source on the Internet. My personal devotion to the project – while there still is some – has proven not great enough for me alone to perform all the necessary responsibilities in keeping the project alive. And, though I still think it’s a useful application, sales and feedback during the time I was actively promoting it make me pretty sure there isn’t a lot of profit to be had from the concept, especially in an hour-for-hour comparison with my real job. So, eduLogon is now free for desktop users, and available for improvement by developers under the GPL. I hope this new licensing allows the code to improve and a greater number of people to get use from it.

Project status update

Saturday, April 25th, 2009

Thought I should provide some notes here about where things are at / what my disposition towards eduLogon is at this point.

I have simply not had the time to work on it since early this semester. There are still some bugs with it that I experience personally, so I know it needs more work. I also recognize that it would be useful on other platforms (read: Apple, both mac & iPhone…) and perhaps even linux too, and that the (surprisingly substantial) codebase behind the existing Windows version would represent a sweet jumping-off point for anyone interested in tweaking/bugfixing/dabbling in Windows/.net programming, since lots of the hard work is done already.

I will be graduating in the not very distant future and relocating to the cities, where I will immediately begin full-time work as a software developer. I have a fiancee and a number of interests that I want to spend off-time on, but eduLogon is one of them. So, for the time being I am going to wait and see how much time I end up putting into eduLogon over the summer. If I do find the time to work on and improve it, I will retain the source code and licensing model and again run a publicity campaign (at the main U too, this time) at the beginning of fall semester if I have confidence in the stability of the code at that point. If I do not end up putting much into it all summer, I will remove the licensing and release the code on sourceforge. I’ll try to alert ACM clubs/CS departments at UMD and UMN of its availability in hopes others have interest in playing with it or writing open-source versions for Apple or Linux. I will remain active in the development if this occurs, ie to support questions about the Windows version, keep the website up-to-date with any new versions that result, and verify and digitally sign authentication server URL’s for new campuses.

Release 1.0.3302.29591

Thursday, January 15th, 2009

Is now the file available for download. It corrects two bugs, one of which was present in all previous versions and one of which was added in 3299.

  • All previous versions were making three duplicate and sequential requests to test sites when the test site trigger was an http redirect and the the user was not authenticated. This is fixed, and authentication testing is now much faster.
  • Fixed a regression in 3299 which prevented the authentication status from being determined when the expected response from a test site was an http redirect.

Release 1.0.3299.36180

Monday, January 12th, 2009

A minor update from the original release, which was 1.0.3294.41949. This release primarily fixes a crash, but here is the full list of modifications:

  • addresses an unhandled exception when systems resume from hibernate (no actual error was occurring, and the exception could safely be ignored, but it produced an “Application has encountered an error” dialog)
  • has different connection timeout and retry settings during authentication status testing, should yield faster results
  • suppresses the purchase notification entirely during the first 20 days of the 30 day trial (only appears 1 in 4 times afterwords.)
  • no longer hides the system tray icon by default
  • reports agent version as part of the user agent http header when authenticating
  • reports campuses used at to the activation server (marketing data)

eduLogon version 1.0 released; protected by CodeWall

Thursday, January 8th, 2009

Since my last post, developments have been very fast-paced. The project’s inception was four months ago, and finally everything has come together. Today I am proud to be releasing the first publicly available version of eduLogon.

Google checkout integration is complete. Activation server-side and client-side code is complete. The software has its own logo/color scheme/branding/fancy website/slogan with the help of some graphics and design assets that I purchased rights to. Various minor bugs and improvements were coded. I have reached an agreement with CodeWall technologies, a vendor of a powerful .net code obfuscator/decompilation protector, to secure the distributed binary from cracking/hacking attempts. UMD’s IT department (of which I am also a student employee) got wind of the project, and the department’s director weighed in. They have some non-technical issues related to perception of affiliation etc that I am working with them to address, but it sounds like there won’t be any drastic decrees that the software is not to be used on the UMD network or anything, so for the most part I think I’m good on that front.

One last security feature has been added to the code – it is now not possible to edit the logon service urls in the xml.conf file to coerce eduLogon into sending passwords to unauthorized servers. The urls of authorized university authentication servers are now digitially signed by me, and if the address appearing in the conf file does not match the signature, eduLogon displays a security warning, and will refuse to send any saved passwords to the addess that is listed. The user can elect to manually enter a password if they want, but only after they have been informed of the security concern. This way, hackers cannot make malicous changes to the configuration file, but users at unsupported campuses can still write and test valid configuration files for their campus, a feature I wanted to preserve so that eduLogon can proliferate.

I won’t start the promotions campaign until the 20th, when spring semester classes begin at UMD, so barring the discovery of any issues in 1.0, things probably will be fairly dormant until then. Still, I do feel pretty accomplished to have put it all together, put to real-world use all my programming education and experience, and released my first commercial software application.

And the winner is…

Wednesday, December 31st, 2008

Over break I have designed and almost finished implementing a custom software activation system that is a function each user’s MAC address(es) and draws inspiration from RSA public-key encryption (or really, more specifically, I reinvented digital signing, then realized that’s what it was…oh well..) Basically, the very server this blog is hosted on issues product keys to the payment processor when purchases occur, the payment processor delivers the key to the customer upon a successful transaction, and the customer enters that product key in the eduLogon agent software. The software sends the key back to this server for verification, along with the MAC addresses of all the physical network adapters present in the system. If the server approves of the product key supplied, it generates cyphertext of each mac address using a private key, returning that cyphertext to the software. The software stores the cyphertext the activation server generated for it and remains activated as long as it finds at least one match between the MAC addresses present on the system and the result of decrypting each cyphertext MAC using the corresponding public key.

I have also implemented a 30-day trial period, and vastly improved the reliability and capability of the custom notifier, which I had a basic version of ready for beta-2, which I never released because it would have been mostway through finals week and probably would not have produced any in-the-field test results.

Now, with all of this in place, I am targeting a first full and publicized release to coincide with the beginning of spring semester @ UMD. I have settled on $3 as the sale price per copy, and finally yesterday could put off selection of a payment processor no longer. I spent a considerable number of hours pouring over the business and technical documentation provided by probably a dozen payment processors…Kagi, Swreg & all the other fronts of Digital River, Regsoft, Plimus, and more. I even wrote a test integration for Swreg…only after which did I find out they have a minimum $1.50 commission, immediately ruling them out when your product sells for $3, and that they could not deliver my product codes except via email. In fact, the only payment processor of these that I could confirm from documentation will give customers their product key immediately on the website as part of the order confirmation was Google Checkout, which also is claiming a mere $0.20 + 2% commission, or only 1/3 of the next cheapest, Plimus. And so, the winner is Google Checkout.

Actually, all that is left to be done before said release is completion of a web service that interfaces with the Google Checkout API, completion of a web service that generates the above mentioned cyphertext (substantially done already), and sprucing up the website/branding the software a little better.

Cisco NAC Appliance (“Clean Access”)

Monday, December 8th, 2008

I wanted to say a few words about my take on Cisco’s network access control solution, which enjoys widespread market share on college campuses, and also has client-side authentication software that essentially would compete with eduLogon. Cisco’s NAC is a very interesting animal, in that besides network authentication, it also attempts to perform what as far as I can tell equates to pretty superficial security checks on host systems, and then only if the host that is authenticating seems to be running Windows – other platforms usually get unrestricted network access to the network upon successful authentication only.

I considered attempting to support Cisco NAC protected networks, since they are so widespread. On the plus side, the techniques for both emulating the Cisco client software and/or persuading the server you aren’t running windows, thus bypassing the need for Cisco client emulation entirely are both well understood. (Cisco’s server now employs TCP fingerprinting to detect windows clients when the HTTP user agent field doesn’t indicate one, so platform spoofing is not trivial.)

However, I have decided not to support Cisco NAC at this time for the following reasons:

  • Cisco already has client software that would compete with anything I produced
  • Cisco NAC re-authentication periods default to one week, making the use of an automatic authentication agent negligible at most installations anyway. (This is also amusing, since on unsecured wireless networks you could probably gain network access by doing little more than MAC cloning the guy that just left, though I don’t know that for sure…)
  • Circumventing the extra security hoops windows hosts are supposed to jump through would presumably go against the desires of the institutions who have implemented Cisco NAC and expect their windows users to perform Cisco’s version of secure host verification. It is my intent to work with University IT departments, using the authentication systems they have put in place only as intended.
  • Circumventing the extra security hoops windows hosts are supposed to jump through would put me at odds with Cisco, which potentially could lead to an iterative code war which I have no interest in getting wrapped up in. For all I know there’s also legal ramifications.

Therefore, the bottom line is although this accounts for a big chunk of the wireless network authentication market share at Universities, I currently do not intend to support sites using Cisco NAC / Cisco Clean Access or Perfigo products.

Hello, World

Monday, December 8th, 2008

This is how I always start blogs. Actually this is only the second I’ve started, but the last one began “Hello World” as well. So technically it is how I always start blogs.

Anyway, the only real objective of this, the first post, is to outline the purpose for the existence of this blog, and what readers can expect to find here. I will be recording progress in the development and evolution of the edulogon agent here, both for my own reference and for the perusal of anyone interested. This will likely include decisions about the direction I’m taking the project, and my rationale for making those decisions.