Cubic

Earlier today, I had a "free heart attack" when a new thread showed up on the PHP Internals list: [RFC] more secure unserialize() I love serialize()/unserialize() because it is nice and easy to use. Unfortunately, with ease-of-use comes greater responsibility. In this case, it is important that users can't submit their own serialized data structures to the server. When the server calls unserialize(), it expands out any data type, including objects. Upon destruction of an object, __destruct() is called by PHP automagically, which then executes whatever code is in there. The "free heart attack" I mentioned earlier came from the fact I send serialized data to the SSO client in the encrypted cookie. Fortunately, a look at the encrypted cookie code revealed I had been using json_encode() and json_decode(), which allowed me to breathe a sigh of relief. For now. This just goes to show that security is a moving target. Or, if you are a cow, it is a moooooo...

I've been looking for an alternate to find + grep under Linux so that I can do similar queries to 'findstr' under Windows such as: findstr /sic:"my_function" *.php Recursive search for PHP files containing the string "my_function". The typical response to "how to search for some type of file containing some text" under Linux is usually along the lines of: find "*.php" -exec grep -H "my_function" {} \; Not only is that cryptic and longer and more difficult to type, it fires off a new, separate process (grep) for every PHP file it finds. I've seen a zillion incarnations of the above. Every time I run that, I end up waiting ten times longer than I would have waited for 'findstr' for the same operation. find + grep performance is terrible. So I said to myself today, "Hmmm...maybe grep has the solution already?" Lo-and-behold, it does: grep -nir --include="*.php" "my_function...

If you are in the mood for a not-so-boring "technical novel" (there apparently is now such a thing), may I recommend reading this lovely 730 page book: Engineering Security by Peter "Long-Winded" Gutmann Reading it does require a level of technical expertise and understanding of how SSL/TLS, SSH, IPSec and a number of rather boring protocols work to truly appreciate what he has to say. For those who don't have the time to read 730 pages, I'm going to summarize: Security, or at least the average programmer's understanding of it, is...severely lacking. We've had two decades to figure out how to not screw up security and, yet, we still find new, extraordinarily stupid ways to do so. The real problems are a lack of accountability in software development and that anyone can own a computing device without any training whatsoever. The book then proceeds to attempt to describe fixes for the problems, but I'd wager that around page 50 or so, mo...

Extremely important update: The technique described in this post has been directly confirmed to extend the block size of any symmetric cipher to any desired length by Bruce Schneier himself - he is one of the leading crypto experts in the world. Ladies and gentlemen, we have a winner! On the other hand, the other aspects of this post remain untested, so keep that skepticism handy. However, this post is good news in the event of a major cryptanalysis breakthrough that breaks multiple widely-used and trusted algorithms. Stay tuned...hopefully more good news to come! Before I begin, I need to preface this with the fact that I don't consider myself to be a cryptanalyst. Coming up with a new cryptographic algorithm that is deemed strong is hard to do and really takes a team of people. I know enough to be dangerous. Therefore, what is presented here is to be viewed as merely a theory to extend the block size of any trusted symmetric block cipher without modifying the core algor...

That is the question I've been asking myself lately. Mailing lists used to be a staple communication mechanism on the Internet. Now nearly all of the mailing lists I'm subscribed to are very quiet - still have 10,000+ subscribers on most, just no one seems to use them. The distinct trend I am noticing is that people are forgoing mailing lists and using quick question and answer sites like Yahoo! Answers and StackOverflow to get the answer to their questions. (Or using the Facebook commenting system or Twitter - but that depends on your friends, connections, and followers). Experts Exchange used to hold the position and used to do quite well but then shot themselves in the foot by putting annoying barriers in the way. People went back to mailing lists after that fiasco. Unfortunately, there are two significant problems with the Q&A websites out there that mailing lists solve and StackOverflow is demonstrating the problems quite well. The first problem is community ...

When I set up my Postfix + Dovecot + MySQL installation, I wanted GMail-like filtering for my domain. GMail allows you to do 'youremail+whatever@gmail.com' and it will automatically be delivered to 'youremail@gmail.com' with the label 'whatever'. From there, it can be filtered into the folder of your choice. I figured something similar would be very useful when registering on websites where I'm not necessarily wanting to use a mailinator address but do want to track whether they sell my e-mail address or not. Well, I thought doing the same thing would be useful, but more on the difficulties I've encountered with special characters like '+' in a bit. In MySQL, I have 'virtual_aliases' and 'virtual_users' tables. If I remember correctly, Postfix first attempts to find an e-mail address in users, then aliases, then tries again without the extension specified by 'recipient_delimiter'. To set up Postfix with a 'rec...

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 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...

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 ...

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...

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...

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 ...

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...

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 ...

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,...

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...

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...

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...

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.

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....