Skip to main content

Posts

Showing posts from 2012

Portable Apache + MySQL + PHP for Windows

I'm a big fan of portable apps. They aren't exactly useful as they were intended on a USB thumbdrive, but put them on a regular hard drive and they blow the installer based versions out of the water. One of the big, missing portable apps is an Apache + MySQL + PHP combination. Well, today, I've resolved that issue: Portable Apache + MySQL + PHP for Windows I built the core of that in about 24 hours of work. It took me another 72 hours before completing this application because I needed this: CreateProcess() API for the Command-Line I had to develop that because Apache refused to run in the background (not as a service) detached from the console. Do you ever get the feeling that sometimes you have just dropped a nuke on a fly in terms of problem solving? With the second application, I totally got that feeling as I was developing it. Anyway, I hope you get a lot of use out of these nifty tools!

Dear sign in providers: Users and developers want these features!

Dear Google, Facebook, Twitter, etc., I've got a nice, ready-to-use Single Sign-On system on my website. I've implemented a couple of providers (Google and Facebook) and, during my interactions with users and developers online, I've come up with a short list of a few things that I see as things that are must-haves that you need to change about your services to make it easier and more sensible to integrate with. First, I should be able to pass a couple of URLs to your server that will display two links on the page where the user authorizes access for my application. Specifically, links to Terms of Service and Privacy Policy documents. These are legal documents and, without them, they open up the possibility of legal liability for the service that you are providing authentication for. Not having them defeats the purpose of providing the sign in service in the first place. A Privacy Policy or similar document also affords the perfect location for users to see why I&

Victim of GitHub: Changelogs

GitHub is pretty awesome. It represents just about the perfect balance of everything software developers have been longing for, which sums up why it is popular. But there is a victim: Changelogs. Before GitHub, the "changelog" was the mainstay of software releases. It told users of a particular piece of software what was going to go horribly wrong should they upgrade to the latest version. It was the primary form of communication between the developer and users of a given piece of software. It tended to be highly technical but an observant user could identify potentially problematic areas of the software and test those areas in their environment before deploying. 'git' encourages fast, quick changes along the lines of "release early, release often". GitHub, based around git, is therefore directly affected by any side effects of git. Development becomes more of a stream of consciousness rather than blocks of development with set milestones and a

Dealing with bad purchases

There is something emotional tied to every purchase we make. We spend time deciding which option is best, maybe check out review sites, and, at some point, cross our fingers and hope that the purchase decision is correct. Of course, a percentage of the stuff we purchase will end up, for all intents and purposes, be total duds. There is a threshold of expense that determines how far we will go to make a dud somewhat tolerable to work with. When it comes to computer technology that tends to be expensive, we are willing to waste hours on the phone with technical support just so we can get back to our lives. So, where is this post coming from? Well, back a couple years when netbooks were all the rage, I saw an opportunity to pick up a cheap Linux box via a Dell Mini 9 pre-installed with Ubuntu. It was $200 and I had plans for it and it has come in quite handy a few times for purposes I never really intended for it. It would have been a worthwhile purchase except for one little te

How to Correctly Flash a BIOS

Every computer comes with what is known as a BIOS (Basic Input/Output System). The BIOS contains startup and basic execution code that runs code before the CPU is handed control. In essence, it is the key piece of software on the computer that makes a computer start up in the first place. Occasionally, motherboard manufacturers will release new versions of a BIOS, usually to correct manufacturing defects. Flashing the BIOS is a rather dangerous, but sometimes necessary operation. Doing this is also usually much more complex than it needs to be, which not only acts as a deterrent but also vastly increases the possibility of something going horribly wrong. Before you go any further, heed this warning: Flashing a BIOS can brick your motherboard no matter how careful you are! Read everything two or three times and have a plan of action and a backup plan if flashing the BIOS fails spectacularly. There is a right way and a wrong way to flash a BIOS. The wrong way is to do it fro

How to identify websites with weak password storage

A lot of high-profile hacks have been in the news lately and various tech journalists are trying to sort through how to fix the problems of weak password selection and password storage that are rampant. While I have technical solutions to the problems , you, the user, are at the mercy of most programmer's whims. However, there is something you can do about it. Once you know what to look for, you can identify websites that have weak password storage mechanisms behind the scenes. Today, I'll show you how to identify those websites that are storing your password incorrectly so you can contact them and educate them. There are several common ways that passwords are stored: Plain text. Encrypted. Hashed. Salted and hashed. 'bcrypt'-style (bcrypt, scrypt, etc). If you use a tool like KeePass, you will run into quite a few websites that store passwords in plain-text and possibly encrypted with a single key. The programmer thought "15 characters is plenty

How to calculate Password Strength (Part III)

This is the conclusion to a three part series on calculating password strength using a brand new algorithm that I've been teasing about for a while. Read Part I and Part II for the earlier bits to this story. If you are a programmer and just want the tl;dr nitty-gritty (i.e. the source code to my algorithm), then you will need to download the SSO Server and Client and extract the code from 'server/support/functions.php'. The two relevant functions are: SSO_GetNISTNumBits($password, $repeatcalc = false); SSO_IsStrongPassword($password, $minbits = 18, $usedict = false, $minwordlen = 4); The algorithm I developed essentially attempts to break a password in an optimal amount of time (less than 1/4 sec). But how does one do that? The first step is to calculate the entropy of the password. NIST has done some work in this regard but they only published a set of suggestions not actual recommendations. The next step is to apply a threshold at some acceptable bit le

The correct way to validate an e-mail address

If you are using regular expressions, in general and not just e-mail, you are Doing It Wrong(TM). Every single time I've ever seen preg_match() or the equivalent function in another language used, not just for e-mail addresses, I know that the code in that location is wrong. The regular expression will miss something important and either be too strict or not strict enough. This is especially true for e-mail address validation. I have yet to find a circumstance where a regex pattern match is a valid solution. It acts as a blacklist and blacklists are constant maintenance nightmares. Regular expression string replacement, however, acts as a simple whitelist. preg_match() = bad, preg_replace = good. But preg_replace() is not what programmers use to validate e-mail addresses nor is it a good idea. The correct way to validate an e-mail address is to do exactly what the RFCs say to do: Implement a state engine that parses the address one character at a time using the complex

LinkedIn, eHarmony, and Last.FM hacked - How to not be the next victim

If you have been following the news lately, you know that business social media giant LinkedIn, the popular dating site eHarmony, and the used-to-be-popular-before-the-merger music site Last.FM were hacked and part or all of their databases were stolen and passwords cracked. This is what happens if you are a beginning programmer who writes a login system. These sites were mentioned in the news because they are larger data breaches, but there are thousands of compromised sites every day that you don't hear about. Don't be next. Instead of authoring a login system, you should be using a product written by someone who has spent the time researching industry best-practices and carefully and painstakingly crafted each aspect of a modern login system. http://barebonescms.com/documentation/sso/ That is an enterprise-grade, Single Sign-On system (written in PHP, but the client is portable to other languages). I'd mention other products but, as of the time of this writing,

A data communication standard - OData vs. GData vs. homebrew

Today I discovered OData.  Then I discovered GData.  Then I discovered that I don't like either one. The idea of a data standardization protocol is appealing on the surface, but the two "official" implementations of a common web protocol for data consumption are not my cup of tea.  I do like tea, however.  But I'm picky about my tea and I'm picky about how I communicate with web servers. First off, I don't like complicated protocols.  I find them annoying as do most other programmers.  This is one of the reasons why SOAP slipped on itself and fell on its derriere at the starting gate.  /hahagreatjoke I've been working with JSON a lot lately.  It benefits greatly from having native support in every popular scripting language and easy-to-integrate libraries in the few languages that don't.  So, if we want to develop a standard protocol, JSON is the starting and ending point for modern development. For some strange, bizarre reason, when a company

Creating Flexible Relational Database Tables via Data Serialization

I thought about titling this post "How to make a DBA's head explode" or "The blog post from hell:  A DBA's worst nightmare come true" or something like that.  Of the database administrators (DBAs) I've met, which haven't been that many, none of them liked my radical database design ideas. Traditional database design says to create a field (column) for every little fragment of data you want to store.  I've found that this approach causes all sorts of immediate complications both at the database design layer and the application layer, and you have to nail the table design right off the bat or there will be big problems later on.  A lot of people get lost in the details of creating the database table and then lost in the details of linking the application to the database.  Good database design is perceived to be hard and therefore a good portion of the DBA's job is secure. Over the past 1 1/2 years, I've been playing with an alternate ap

Dear Web Developers, Stop making login systems

It seems to be a rite of passage to author a login system - or several login systems - over the course of one's life as a web developer.  Some systems are more elegant than others but I have to ask:  Is it really necessary? Let me provide some background.  I was mulling one day and realized that every website I've ever come across has one of two problems: Multiple login systems all over the place with multiple registration mechanisms (the result of using open source products or just bad programming habits). Some homegrown, half-baked solution riddled with security issues and poor UI design choices that breaks in half the browsers out there and irritating every user who uses the system. Or some mix of both problems.  And don't think it is just limited to cheesy little one-off implementations.  Major big-name websites that people actually use every day are all in the same boat with the little dinky one-off sites. Then I got to thinking about how many man-hours are w

Migration to new web server 95% done

A few of my websites went down over the weekend as I moved them over to a new server.  I've been saving moving my two primary domains for a while but I had to bite the bullet and move them due to issues involving storage space. Let me say that I am incredibly happy to have moved my hosting over.  Particularly e-mail.  I spent several months carefully crafting a fairly intricate e-mail setup with postfix and dovecot.  Totally worth the effort.  I've eliminated approximately 95% of all incoming spam.  The difference is night and day:  deluge vs. sprinkle. Everything is running over SSL/TLS for e-mail.  And I'm using SSL/TLS for web administration. The downside is that I lose all of my ancient website layout for my main website.  The site was basically dead anyway so I turned it into a one-page site instead of the ugly mess that it was.

Free E-mail to SMS/MMS Gateways in JSON format

I just released a new project on GitHub: https://github.com/cubiclesoft/email_sms_mms_gateways If you aren't a developer, then you probably won't care.  Basically, I burned my weekend constructing a JSON array by hand that maps countries and carriers together that provide a free e-mail to SMS/MMS gateway.  Well, it is free for software developers.  Charges, of course, still apply to the recipient of the SMS/MMS messages. GitHub makes it really easy to keep that mess up-to-date.  Other people supply pull requests, I click a button to accept them.  Bam!  The list is updated.  Then everyone using the list pulls the latest list and...Bam!  Everyone's software is running with the absolute latest information.  It is a nice, clean system. I've got a use for this project but it is going to play a smaller role than I originally dreamed up. Carriers need to get their act together and form a consistent strategy that developers can rely upon.  Standards committees exist for

Google's new Terms Of Service and Privacy Policy are fine by me!

I've read a number of articles out there about Google's new push to unify their Terms of Service and Privacy Policy documents.  Most of the articles are about "privacy experts" complaining about how great the old documents were.  I have a question:  Who gets to decide when someone is an expert?  Is it some specific minimum level of knowledge?  If so, I just ooze knowledge and therefore that makes me an expert on stuff. Anyway, I'm glad Google is unifying their 60 or so Terms of Services and Privacy Policies into just one AND being open about the change long in advance.  Nobody reads these things anyway and is just a way to cover a business' rear end from frivolous lawsuits.  After all, hot coffee is hot...well, duh!  It doesn't matter how the McDonald's vs. Hot Coffee Lady case actually went down because it is a symbol of today's messed up legal system. Back to topic, Terms of Service and Privacy Policy documents are usually a pain in the neck

How to calculate Password Strength (Part II)...

Previously, on Cubic :  The main character introduced a broad analysis of a new algorithm for calculating the entropy of passwords so that a threshold may be applied and weak passwords rejected.  Will our hero's new algorithm pass more rigorous testing or will his arch nemesis Statistics Boy defeat it?  Let's find out! Since my last publication, I've been busy doing some other things.  But this week I got back to working with this algorithm to see how good it actually is.  My primary goals with my tests were to figure out how well it performs against real-world data and to determine a baseline entropy threshold for the algorithm that rejects most bad passwords.  And what better real-world data is there than to use databases of passwords that were stolen from hacked websites? I ended up testing against two types of information.  The first type were hacking dictionaries.  These are specially formulated files designed to defeat commonly selected weak passwords.  The latter

The Ultimate Chair (Partial Resolution)

A while back, I wrote a series of posts of creating a chair that would allow me to sit outside and soak up some rays.  Programmers are white and nerdy because they sit inside.  There are several benefits you can get from going outside: Fresh air The sounds of nature Sunlight Knowing what time of day it is Not looking like a pasty-white programmer/office worker Anyway, this post was an itch I've been meaning to scratch for a while to provide some closure and someone finally commented on it, so here goes... I used the chair for a few months.  (Feel free to take that sentence out of context.)  And it sort of worked.  It got me outside but I had several problems that I could never resolve to my satisfaction: 1)  The chair itself wasn't comfortable to sit in for an extended period of time.  I hate anything that provides so-called "back support".  As an intelligent alien lifeform on Earth (that's a joke, BTW), back "support" is more like back "