Coding4Fun Book News

Now that we have finished writing the book, we finally have an official title and chapter listing.  Someday we may even have a cover.

The title has morphed into Coding4Fun: 10 .NET Programming Projects for Wiimote, YouTube, World of Warcraft, and More and the final chapter listing (not necessarily in this order) is:

• Alien Attack: Create a 2D clone of Space Invaders with XNA for the PC, Xbox 360, and Zune
• LEGO Soldier: Create an action game using Popfly with a custom-built virtual LEGO character
• World of Warcraft RSS Feed Reader: Use WoW's customizable interface to have feeds pop up while you're gaming
• InnerTube: Download YouTube videos automatically and convert them to a file format for off-line viewing
• PeerCast: Stream video files from any PC
• TwitterVote: Create custom online polls on Twitter
• WHSMail: Build a website with ASP.NET for Windows Home Server that lets you view the messages stored on a computer with Outlook
• "Wiimote" Controlled Car: Steer your remote-controlled car by tilting the Wii Remote controller left and right
• Wiimote Whiteboard: Create an interactive whiteboard using a Wii Remote
• Holiday Lights: Synchronize your holiday light display with music to create your own light show

We also have an official web site for the book located at http://www.c4fbook.com/.  This will be the “go to” place for source code downloads, forum discussions, updates to all projects as we continue to work on them, and everything else you will need to fully enjoy the book.

Get your pre-order in now and save 34% off the list price at Amazon!  Or, buy from O’Reilly with another book and get a 3rd free!

posted @ 9/4/2008 11:00 PM by Brian Peek

TUX Update... (AKA I missed something)

MSDN Premium Subscription is up for grabs

I forgot to mention this yesterday. Bill Reiss our resident MVP is giving away an MSDN Premium Subscription. So if you come you have a chance at getting it.

Multi-location

BTW, we are working toward being multi-location, so if you are in another state in the US (probably more of an East Coast thing) or in Florida, one of our goals is to make our meetings available via streaming (but only to groups... sorry you won’t be able to just dial up our stream from your desk at home)

posted @ 9/4/2008 4:27 PM by Jay Kimble

TUX (Tampa UX) is next Wednesday (Sept. 10th) at 6:30pm

The Tampa User eXperience User Group will have its first meeting next Wednesday. The presentation will be MS Ajax Client Script 101 by Jay E. Kimble (me). We will be meeting at  Answers Systems (4029 Tampa Road, Oldsmar, Fl 34677... right next to the Oldsmar Fleamarket).

Email me if you are planning on coming (use the contact form on the site). I will post my cell phone a day or two before (so you have someone to call in case you get lost).

Pizza and drinks will be supplied, so come on out.

posted @ 9/3/2008 8:53 PM by Jay Kimble

Prognostication.NET

"C#, .NET, Visual Basic, FoxPro, COM."

"What are Microsoft technologies that should have died by now?"

It's really interesting how the development community, in light of being a community of engineers, is so enthralled and passionate about subjective analysis and fortune-telling. I recently ran into a few online conversations with some long-time friends that lead me to think back to around 2001 to 2003 - a time rife with predictions about Microsoft technologies - and how most of those predictions never quite panned out.

After the J++ lawsuit debacle, Microsoft decided to take Sun head-on with a brand new (yet another) C-derived language: C#, and its accompanying runtime and base class library. Right from the get-go, Microsoft had a hard time making people take the language seriously, even having to spend an inordinate amount of time explaining how the correct pronunciation was "see-sharp". Well, after 8 years, C# is alive and kicking. And so is the .NET stack. Few Microsoft shops would rather develop solutions in anything else these days. Interestingly enough, while C# borrowed much from other environments (including Java - and not forgetting that Java itself is heavily derivative), Java has in the past few years adopted many things from the C# language, runtime, BCL and IDE.

VB has had a standing obituary for over a decade (which never quite proved to be reliable), but never a more pronounced one than during the first .NET release. People who always hated VB and "classic" VB aficionados alike derided the new "abomination" called VB.NET and perfunctorily declared Visual Basic dead. For some who were passionate about classic VB (and even classic BASIC, if ever there was such a standard), it was not merely that the VB flavor they knew and loved was dead and replaced by this thing so-called Visual Fred, VB.NOT, B#, or C-flat, but also that the new critter in VB clothing would be dead before long as well. Nothing could be farther from the truth. VB in its current incarnation is still the leading Microsoft development language (in terms of market share), beating both C++ and C#, and C# by a landslide at that.

And while Microsoft, in a series of (monumental) marketing and technical blunders and omissions, has shut VB out of certain niches, VB's market share still rivals that of Java according to Forrester, much more so than C#.

Of course, the opposite was also stated - that classic VB would die before long. Perhaps the feeding tube and respirator have been removed, but VB6 has shown a stubborn resilience and unwillingness to fade into the sunset. To me, that's hardly a surprise and only validates what I've said all along - that any development technology that is sufficiently adopted simply can't disappear in a short period of time. Chances are that one of your banks/credit-institutions/card companies/utility companies is still running a 15+ year old COBOL application.

FoxPro. OK, Fox is gasping its last breath if you can't exactly call it dead. It's not really feasible to see that any other way. Unlike VB, FoxPro won't get a reincarnation. However, it does leave behind a legacy. It seeded many of the ideas behind some of the SQL Server tools as well as being an inspirational source for LINQ.

For some who were absolutely giddy about .NET, there was the prediction that all other non-.NET development for the Microsoft platform would fade away - and most specifically, with regards to COM. Look, COM is most certainly a pain in the backside, but I always said it was far too ingrained near the heart of Windows to ever be removed. Like Iron Man, the best you can do is isolate yourself from the shrapnel with a shiny piece of technology. And MS isn't abstaining from developing new things with COM either. For 2005, the entire SSIS pipeline was built specifically for... you guessed it, COM.

Having said all that, there are some things that have indeed bought the farm. Most of them were first stabs that proved somewhat inadequate. The biggest example I can find is Remoting. Not that there was too much wrong with the technology, but it simply wasn't as encompassing or as flexible as its successor, WCF. Of course, Remoting is more like undead than dead (it's still fully supported in the framework, but won't get any fixes or additions), still limping around in (now) legacy applications until someone gets the time to migrate it over to WCF. And WCF is a bit overwhelming for the average crowd, with all its buttons and levers. Of course, if you can complain about WCF's complexity, Remoting is probably not your thing either.

A number of binding technologies seem to be destined for the same fate as well. I don't know if it's just me, but binding is always in a state of flux and nobody ever seems to *finally* get it right once and for all - a state of affairs that I'm sure leaves the anti-binding group in a standing ovation.

And moving forward, I will throw my own prediction into the hat. It's hard to see that LINQ to SQL will survive Entity Framework. It would be a ridiculous situation to have LINQ technology, and yet have no way to query into a database using it. LINQ to SQL seemed to be a ready candidate to fill that hole for the initial release. But it's an extremely poor OR/M, if I'm even allowed to call it that, and is rife with limitations that make it impractical for a lot of scenarios. EF, on the other hand, just isn't finished. It's an ambitious vision to be sure, but once it's done, you will have a much more flexible system that can connect to multiple data sources (not just SQL Server), easily plug into custom entities, removes the lame 1-to-1 mapping between tables and entities, and all while keeping with a simple set of similar designers. In other words, it would effectively do everything LINQ to SQL does and much more. It's also being worked into the guts of ADO.NET Data Services as well.

posted @ 9/2/2008 11:27 AM by DevPrime

User Interface That Works - The Microwave With Only 4 Buttons

At work we have a very simple microwave with only 4 buttons (not counting the door open lever/button):

This microwave manages to be one of the most effective user interfaces I've ever come across. Pressing the plus ("+") button ups the time in 10 second increments, until you reach 90 seconds, and then it ups the time in 1 minute intervals. Once you pass 90 seconds, the display shows whole minutes. You can't set a time of 17 seconds, for example, or even 6 minutes and 30 seconds.

Pressing the minus button decreases the time by 1 minute if the current time is more more than 90 seconds, and then it decreases the time in 10 second intervals down to zero. Pressing the "Start" button increases the time in 1 minute intervals, but only up to 3 minutes.

All this I've figured out by experimentation. I reckon it's the lack of numeric precision and the associated traditional numeric keypad that makes this 4-button microwave so effective. The "+", "-", "Start" and "Cancel" buttons are self-explanatory, and experimenting with them instantly tells you what they do.

Contrast this with the horrible boiling water unit that I blogged about previously, where the buttons are unlabeled (and clicking them does nothing anyway), and the 4-button microwave comes out a long way in front.

Links: http://theruntime.com/blogs/thomasswilliams/archive/2008/04/23/a-short-rant-on-one-example-of-why-over-engineering-stuff.aspx

Tags: design, kitchen, ui

posted @ 9/1/2008 1:13 PM by Thomas Williams

Handling Passwords

There are two reasons I’m writing this post. First, I’ve noticed a slew of articles and blog entries lately about the topic. Now, that’s good from the perspective that it’s an indication of people taking the topic seriously, and also helps to get the word out. Second, I’ve noticed that the authors often have incomplete and/or somewhat inaccurate information, which I’m sure they got from reading someone else’s incomplete and/or inaccurate material. That doesn’t necessarily make it bad, but they write the material with an authoritative tone – because, you know, blog authors are all leading experts in their fields, including fields they decide to wander into on any given day for the sake of a post

For those of you who missed the sarcasm: don’t believe everything you read on the internet, no matter who it comes from. Sounds like common sense, but that includes your favorite bloggers too, no matter how sharp you think they are. And on that note, I’ll give my standard security warning – although I’m pretty handy with math, I do not consider myself a true cryptanalyst. I am a hobbyist, enthusiast, and avid studier of cryptography. While some have considered that would make me something of an expert, I merely study the work of great cryptanalysts and I would prefer to be seen as just a guy who’s about to show you some of the things you need to know. So I encourage you to use this blog post the way you should use any blog post – as a stepping stone to research further, rather than the end-all and final word on the subject. The key being that when it comes to security, most developers just don’t know what they don’t know. Finally, the world of cryptology is steeped in detailed jargon and math formulas. This level of detail is absolutely necessary because in security, the devil is in the tiniest detail (and there are many). However, that level of detail also puts off about 90% of software developers. But since they are the ones who are entrusted with securing software, I will try to keep things at a fairly understandable level. Also, there are a few recent news items related to this topic that just begged to blogged about. So let’s dive right in.

The Importance of Passwords

Authentication is a critical operation for a vast amount of software. Systems need to know who any given user is. All of the user’s access to any given system, what they can and can’t do or see, is determined ultimately by who the system thinks they are. Password authentication works on the principle that a user knows a password that nobody else knows. The software has a record that lets it determine if a given user enters the right password. If they do, the software can be reasonably sure the user is who they claim to be. But in order for that to be effective, you need two things:
1) The password MUST be something that only the user knows. That means that a user must never divulge the password to ANYONE, including operators of the software.
2) It must be physically infeasible for someone else to get a hold of, or guess the password.
In order to get #2 right, the user is responsible for using a password that others can’t feasibly guess. This relates to password strength, which I’ll get to in a minute. It also means that the software must take precautions to forbid anyone but the user from seeing or otherwise getting a hold of the password. This means you should never, EVER, store a password in plain text. Ever. It doesn’t matter who you think has access to the data or not, stuff happens, and before you know it, your entire customer base’s data is in the hands of a malicious data thief. This has happened to MANY large corporations (for example, Citibank) despite their security measures. Besides being bad for business (most states are starting to require companies to publicly divulge when this sort of data compromise happens), some states now have laws that hold you (the data keeper) accountable and liable for data loss and compromise. That means users may be able to sue you if you didn’t do enough to protect their sensitive data.

So why not use something else for authentication? For example, we know DNA, digital fingerprinting, possibly retinal scanning, and other biometrics are unique to a person, and not easily compromised or duplicated. Well, if you lose your finger or eye, it’s gone. If your DNA is ever compromised, you can’t really change it the way you would change your password. It’s compromised forever and you’d be stuck with the option of never doing computerized banking or shopping ever again (which I’m sure would be the least of your worries at that point). So for now, passwords are the “in” thing.

Password Strength

Because this system relies on the basis that only one person knows their password, you, as a user, must be responsible for creating passwords others can’t guess. With only 48 8-bit characters, the possible combinations of letters, numbers, and symbols (before you even touch Unicode) are unfathomable. But there are only a few hundred thousand actual words in any given language, so don’t use real words as passwords. Computers can run through an entire dictionary in less than a second, so breaking such passwords with what’s called “brute force” (checking all possibilities) is extremely easy for a computer. Furthermore, if you use real words, a computer doesn’t have to check all possibilities under some situations (more on that later). But on a computer that can check 1 Billion combinations per second, it would still take tens if not hundreds of trillions of years to go through 48 characters of possible combinations (assuming you could use up all 8 bits in each character). Also remember that as far as brute force attacks are concerned, security improves exponentially (not linearly) with password length. For example, doubling the size of a password doesn’t double the number of combinations, it squares them.

So as far as security goes, you MUST have sufficiently long passwords. I’ve seen systems that require a limited number of characters (around 6 or 8 or so) and this is just not good enough. Anything less than 16 is probably asking for trouble – because on top of the number of bit combinations, people typically only use a limited set of values for each 8-bits (character, assuming non-Unicode). If you only use real words, then a potential data thief has an extremely narrow set of combinations to work with, so it’s important to really mix it up with as many combinations of numbers, letters, and symbols as possible. Also important for both users and software developers is the concept that passwords and validation algorithms must be case-sensitive. In English, with a 26 letter alphabet, you have 52 possible alphabetic characters (upper and lower case), but if your algorithm is case insensitive, you’ve thrown out 26 possibilities for each 8-bit chunk... which drastically reduces the overall effectiveness of the string when considering combinations. Since chances are that you are already working with a set of characters that doesn’t use up all 8 bits to begin with, then you really cripple the system by removing uniqueness based on character case.

This of course, must be balanced with memory (human, not RAM). A password is absolutely no good if the user can’t remember it. So it must be easy enough to remember, and difficult enough to foil guessing. Arbitrary strings of characters usually end up being one or the other, but not both. A lot of passwords are stored in a database, and that becomes one of the most popular reasons for limiting the size. However, there are some techniques which do not limit the size of the password – effectively making them as long as you want (even if they are stored in a database). For such systems, a good alternative is to have a pass phrase. Just like passwords, it’s important to mix things up with letters, numbers, and symbols, but you can use an entire sentence of text (although, you’d probably want to avoid using too many “real” words). It’s easier to remember a phrase of large text than it is to remember an arbitrary albeit smaller string of characters. Unfortunately, few systems allow you to enter as much password text as you want, even if they are capable of storing much larger phrases. However, it is definitely something to consider if you are about to implement a new system. As far as resilience against brute force attacks go, the longer the better.

Storing Passwords

If you are thinking of storing passwords in plain text, just hang up your hat and go home. Leave the system unfinished. It’s simply not worth the future trouble and liability you are subjecting yourself to.  That leaves you the option of somehow scrambling the password so that even if the data is stolen, people won’t be able to discover anyone’s password. At this point, I really need to re-iterate rule #1 of encryption: Do not EVER invent your own data protection algorithm. I know you think you are smart, have an advanced degree, and have been programming since [insert your favorite archaic system here]. But unless you are a cryptanalyst [expert], you will regret it. Data thieves don’t care about your pedigree, and as smart as you think you are, the odds are definitely in their favor, not yours. In fact, crypto-systems’ strength isn’t necessarily measured by the intelligence of the person who came up with the algorithm. Many extremely smart people (I’ll wager smarter than both you and I put together) have created systems that ultimately failed at the hands of some malicious hacker.  Secure systems have withstood many years of attacks and analysis. That’s what you should go with – a standard that has a proven track record with no vulnerabilities found.

Now is a good time to point out there are fundamentally two types of data protection primitives in use: encryption and cryptographic hash codes. The main difference between the two (although many details differ) is that encryption entails an algorithm that can both encrypt and decrypt text – that is to say, it can encrypt a chunk of plain text, and subsequently, it can decrypt the scrambled data back into plain text. On the other hand, cryptographic hash codes are one-way. You can’t “decode” a hash result back into the original plain text.

There are many encryption schemes and algorithms out there, but for the sake of this conversation, let’s just say that all the useful ones require keys. These keys must be securely stored. If an attacker gets hold of the keys, they can decode your entire database of passwords, and at that point, the passwords might as well have been in plain text to begin with. Effective “key management” is very difficult, and I’ll postulate that you shouldn’t have to return scrambled passwords back to plain text anyway (more on that later).

Cryptographic Hashes

Cryptographic hash algorithms have a few important properties:

1. They take an arbitrary amount of text and turn it into a (usually smaller) fixed-length code. Among other things, this makes cryptographic hash algorithms ideal for pass phrases. No matter how long the phrase is, the resulting hash code is a relatively small and fixed size (let’s say 128 or 512 bits or 32 to 64 bytes).
2. Running the same piece of plain text through a cryptographic hash algorithm will always result in the same hash code.
3. They should be as collision resistant as possible. That means that two different strings of plain text shouldn’t result in the same hash code. This is very important and I’ll discuss it later as well.
4. The algorithm shouldn’t be reversible. If all you have is the resulting hash code, it should be mathematically infeasible to run the algorithm backwards (or run some variation of the algorithm or any algorithm at all for that matter) that changes the resulting hash code back into the original plain text.
5. Changing the plain text input, even a tiny little bit, will cause significant changes in the resulting hash code. You shouldn’t be able to approximate the original text by using similar text, as they should result in wildly different codes. There should also be no resulting patterns where the occurrence of a sequence in plain text can be deduced from a sequence in the hash code.

Wow! That was easy. Well, not so fast, cowboy.  We still have a number of vulnerabilities to account for. In order to secure a system, you have to know how people will attack it. You can buy and install the thickest titanium steel door with the most complicated tamper-proof lock and it will do absolutely no good if someone can just go around to the back and open a window to get in. That is what cyber attackers live for, and they are much better at this than most of us. If you just took the preceding section into account, you would be in for a world of hurt, so it would be a good idea to see just how attackers try to get passed the system.

When Dictionaries aren’t Your Friend

The number one reason to avoid real words is that a brute force attack normally has to consider every possible combination. But if you use normal words (and most people apparently do), the attacker can just look at a much smaller set – about 500,000 or so possible words in the English language, for example.

If you just relied on the scheme I detailed above, then the attacker doesn’t even have to resort to brute force. They can use the so-called Dictionary or Rainbow Table attacks. Basically, someone sets up a dictionary of hash codes for every possible word (more complex dictionaries have combinations of text, numbers, etc.). That way, if an attacker gets the stored hash code, their software just looks up the hash code in the dictionary or rainbow table, and viola, they have the corresponding plain text (and it took considerably less time than 13 trillion years).

“So what,” I hear some of you say, “nobody has access to the password storage.” Think again. This is exactly the sort of attack that set entire UNIX networks on fire decades ago. The older Microsoft LanMan scheme suffers from the same problem. Many banks, online shopping companies, and even government agencies have had their data stolen in the past couple of years alone. It can happen to you. In fact, I’ve worked for two companies that hired me after having compromised data.

Salt and Speed Kills Rainbows

In order to foil these attacks, you have to produce hash codes such that pre-generation is infeasible. The first step is what’s called Salt or Nonce. This means that you append a piece of random data to the password before hashing it. This helps to stop even common words from being susceptible to dictionary/rainbow table attacks, but it’s still a good idea to avoid common words since attackers can just use them in brute force guesses. The salt or nonce doesn’t have to be very long. Due to hash algorithm property #5 above, even a small change to the input drastically changes the resulting code. However, the salt or nonce should be of a significant enough size. Let me put it this way – if your salt was 1 bit (0 or 1), then attacker would have to double the size of his dictionary or rainbow table (to account for all the possibilities with either a 0 or 1 added to them). But that’s not bad in terms of the size of the data the attacker needs. However, each additional bit of salt or nonce exponentially increases the combinations (just like increasing the size of the password itself – same concept). At a certain point, it becomes totally infeasible to pre-generate a table of possible values.

In fact, most commonly available (albeit older) rainbow tables have up to 8 characters, so generally-speaking, your passwords should always be more than 8 characters (although I seriously recommend at least 16), and you’ll weed out most of the wannabe attackers out there.

More importantly, each hash code should have its own UNIQUE and COMPLETELY RANDOM salt value. Do not compute the salt based on the input or use the same salt for every password. This makes the salt value predictable and helps the attacker narrow the amount of data they need for a dictionary or rainbow table. The introduction of unique and random salt or nonce also means that two people using the same passwords will have wildly differing hash codes stored in the database, which is definitely a good thing. Ideally, the salt or nonce should be created using a cryptographic random number generator, which is vastly more unpredictable than a standard time/seed-based generator.

Of course, in order to use the password + salt, you need to validate using the same salt value later (when the user enters their password for authentication). Fortunately, the salt doesn’t have to be a secret. You can just store it with the password hash code.

If you think salt isn’t enough, there are other strategies you can use in addition of salt or nonce. One of them, which I’m pretty fond of, is iterations. This means repeatedly hashing the password + salt. Basically, you take the initial password plain text, add the salt, and hash it. Then, you take the password again, add the salt and resulting hash code from the previous round, and hash that. Then repeat a few thousand times (or more). If salting helps to deter lookup attacks, iterations make it almost impossible with current technology. Some schemes like MD5-Crypt use 1000 iterations, but I prefer 10,000 or more. Even that number is relatively fast (less than a second), and you only use it when someone creates a password or attempts a login. This also makes input brute force attacks that much slower.

Birthdays Ruin Security

Here’s a neat little bar game that people have been playing for a long time: Walk into any bar (or office, or anywhere that has more than 20 people) and bet that at least two people there have a birthday on the same day. Some of you are probably thinking this is a really fast way to part with your hard-earned cash, and wondering what kind of dork would attempt that. But in a group of 23 people, there is a slightly more than 50% chance of that happening! If the group is 57 or more, then the chance is more than 99%. For the math behind this little scam, Wikipedia “Birthday Problem” (it’s a fun little exercise, but this post is getting long as it is).

The principle behind this is called collision counting. In this case, it’s how many birthdays collide (on the same day) given the number of combinations. For cryptographic hashes, the same principle applies, but on a much, much larger scale (after all, there are only 365 days in a year for birthdays). Hash algorithm property #3 from above states that they must be as collision resistant as possible, but mathematically-speaking, such an algorithm would almost be susceptible to collisions by definition. A collision here means that two different pieces of plain text input result in the same hash code. A good hash algorithm makes this virtually impossible for most input you would care about, but physically it might actually still happen, and the math behind it all says that it probably will. Clever attackers can try to use the math behind the birthday collision problem to narrow down a brute force (a so-called birthday attack). In that case, they don’t have to find the one piece of input that results in the code – they can attempt to find one of two or more possible choices that will also succeed.

There is very little you can do here except to avoid hash algorithms that have a mathematical flaw which allows for the possibility of a feasible collision. Even collisions at the block level reveal weaknesses that can be exploited. Practically speaking, this means that you probably want to avoid MD5 and SHA1 and anything that came before them. In addition to the potential collision problems, the resulting code is also relatively small. A larger hash code usually helps in many ways, and I would recommend something that’s at least 256 if not 512 bits long (the SHA suite has a few variations that result in that size).

More the Merrier?

So if one hash algorithm is good, two should be awesome, right? Not necessarily. Combing two hash algorithms don’t make the result twice as strong. If you hash a password with MD5 and then again with SHA1, and concatenated the results, there are still inherent weaknesses. Antoine Joux postulated the concept of multicollision, and how concatenating hash codes doesn’t really make them stronger than their component parts. Google “Joux Multicollision” if you want to see all the gory mathematical details.

What about hashing the password with one algorithm and then feeding that into the other algorithm? Still no dice. You’d be at the mercy of the strength of the first algorithm. If the first algorithm was susceptible to and experienced a collision, then it would simply feed the same output to the second one – which almost makes the second one only as secure as the first one.

Bottom line is that it’s best to stick with salt or nonce + iterations, and pick a nice, secure, and proven hash algorithm. And if you are using a premade authentication system, then use these tips as criteria to evaluate the package.

Keyed Hashes

There’s a class of hash algorithms that depend on a key in addition to a hash algorithm (HMAC). Many block ciphers (a type of encryption algorithm) can also be used in a way that effectively makes them a hash algorithm, and they would also use a key as well. But again, the problem is that you have to deal with effective key management. There simply isn’t enough space on this post to deal with that topic. But definitely research it if you are curious.

Forgive and Forget is Divine, but not Secure

So what happens when some user (as is inevitable) forgets their password? A lot of web systems have an “I forgot my password” link, which does a number of different things depending on the site. The worst offenders email your password back to you. This is the most horrible idea ever. You might as well spam the user’s password all over the net. First of all, that email is riding around the net in plain text. Anyone sniffing traffic can intercept it. Secondly, almost every router/switch and server along the path now has a logged transcript of that email.

Unfortunately, forgetting a password is something that, when handled properly, is going to be an inconvenience to the user. But you know what? That’s OK. A small inconvenience is a small price to pay for forgetting your password in comparison to losing your bank account or an account that has a stored credit card attached to it (which would be a whole different security post...).

Part of the reason systems emailed passwords back to the user was that they figured if you are someone malicious attempting to snag the account, the password would only go back to the email of the person who originally registered the account. But as you can see, that really isn’t true. The password just gets smeared across the internet. In a recent breaking story, it turns out that it’s much easier than previously thought to redirect internet traffic due to a protocol security flaw, and you wouldn’t even know it. So don’t think that it’s unlikely someone would be able to see that email.

Who’s your daddy?

Another option is to reset or to allow the user to change the password when they forget. Of course, since the person attempting this operation is anonymous (after all, they’d be logged in if they could remember the password), you have to be careful so you don’t just let anyone reset or change anyone else’s password. You still have to be reasonably sure the person making the request is in fact who they claim to be. A lot of sites these days force a user to record an answer only they know, to some kind of a “security” question. Make no mistake; this is just another method of authentication, and one that is loaded with weaknesses. Since answering the question grants you access to the system – either immediately, or by allowing you to change the password – it is just another password in and of itself. However, this “password” (the answer) is usually small, a normal word, and directly linked to a single question. It is infinitely easier to brute-force! Remember that titanium-steel door? Well, you just opened the window and hung a “welcome” sign on it. You don’t have to be a hacker to exploit this system weakness. A recent divorcee discovered that she kept failing to log into her email. She kept typing in what appeared to be the wrong passwords, and kept having to reset them. It turns out that her soon-to-be-legal-ex kept changing the password on her by using the “security” question, and had stolen all her private communications with her divorce lawyer. The ex did know quite a bit about her life - after all, they were married for many years, so chances were definitely in his favor that he’d know many of the common security question answers she would use. Savvy users will type in answers that make little sense to anyone else, but the questions really lead the average person to type in the worst and weakest kind of entry keyword possible. It’s a horrible system to get people accustomed to.

You are the Weakest Link. Goodbye.

And the sad part is that you don’t even have to be foiled by a close relative or spouse these days. Just about anyone can get a hold of everything they need to get into your account via the security questions. Why? Because YOU are GIVING it away to everyone!

In almost any system, it’s often not the data or the encryption or any code that forms the weakest security link. It’s the people. Data thieves often resort to social engineering attacks rather than attacking the software itself. You are a lot easier to crack than most software if you aren’t careful. That is especially true today in the horribly insecure Web2.0 world.
See, social networking sites are like crack. People check MySpace and Facebook more often than they check on their children. People collect friends like kids collect Pokemon cards. Unfortunately, in the quest to acquire more friends than Jesus and be the most popular kid on the net, you happily publish every last little thought in your skull and every last little detail about your life, how you’re feeling, and what you are drinking or listening to at the moment, knowing that everyone in your friends’ list is just lapping up every inane scrap of brain vomit throughout the day and thinking about just how cool you are and how lucky they are to know you. Of course, they aren’t, but it makes you feel good to think so. But those data thieves are absolutely riveted! Hey, you have fans after all!

That Yorkie fanatic next door, the one with three of the yappiest four-legged mop-heads on the planet – what’s her security question? “What is your pet’s name?” And what’s her blog loaded with? Yep, you got it. Wonder how much money she has in her account today. And the funny part is that the thieves don’t even have to pretend to be Nigerians with a few extra million coincidently sitting in a dusty ownerless vault waiting for you to act now and help them transfer it to your account.

Sadly, it’s not just the average Joe who gets suckered. The crack is so potent that it happens to the experts. In Defcon (a hacker’s convention) at Vegas this year, some of the attendees were friended by (people pretending to be) a number of big-shot prestigious hackers – described as the kind who once got arresting for speaking about some government software vulnerability, who lurk in the depths of secret security mail lists and forums, known to the world only by their net nicknames, who write crypto-defeating math equations that make your brain bleed and the NSA wet their pants. The attendees were more than giddy to accept. And then the fun began. You can read all about these social engineering attacks on social networking site shenanigans on the Defcon official site.
As far as secret info you use for authentication, it’s best to heed rule #1 of information security – Trust No One.

Wolf in eBay Clothing

The other major social engineering attack on passwords is phishing. This is where some data thief sends you an email that looks like it came from eBay (or a bank or anywhere that has an account you really don’t want to lose), usually telling you that your account is suspended, and directs you to a link where you are supposed to log in and verify that you haven’t done something horribly wrong. But instead, the link takes you to some Malaysian website (which is probably also compromised) where a fake login page, that might or might not actually contain the word eBay, sends your password to a script that feeds it back to the data thief. Of course, if your account was closed or frozen, how are you supposed to log in? Oh well, minor details. But phishing is effective, especially among people who have internet access but aren’t very net savvy (like a presidential candidate who shall remain nameless or granny who just uses it to email the family pictures around). It’s effective because they trust that eBay wouldn’t lie to them, and that the page they are going to is in fact owned by eBay.

Server Mug Shots

The problem is that up to now, apps (especially web apps) mostly handle a one-way authentication. Under more secure environments, you have mutual (two-way) authentication. Not only does the software have to know who you are beyond doubt, the software has to identify itself beyond doubt to you.

Up to now, people simply trusted in the URL or the browser’s interpretation of the server’s SSL cert validity. But a lot of people don’t even look at that. It’s simply not obvious to non-savvy users. And even if you think you can tell that the URL is really going to eBay.com rather than www.istealidentities.com/ebay.com, that doesn’t really mean someone isn’t re-routing your traffic. This would seem to be an elaborate trick to pull off, but not that difficult to people who know how to exploit routing protocols flaws, or if there are compromised servers/routers/switches at an ISP.

One of the schemes becoming popular now is image authentication. When a user creates an account, they select a picture from a large gallery of simple every-day items. Only the software knows which image they selected. When they go back for a login, they type their username, but not password. The server then identifies itself by showing the user the image they previously selected. Now the user can type in their password, knowing (reasonably so) that the software isn’t some phishing site. Phishing sites typically aren’t very complicated or dynamic enough to even show a different image, but they also shouldn’t know what picture the user selected. Of course, the number of pictures directly relates to the strength of that authentication, and perhaps it would be better to use phrases, although I suppose the argument is that pictures are easier to remember. The problem is that most systems have no really visible server/software authentication to speak of, and people simply aren’t used to it (yet).

Don’t Come a-Knockin’

The basic point of all these bits of trivia and attack modes is to ensure that you get a system that is really up to par on password security. The system needs to strive to eliminate the feasibility of any attack mode, forcing only brute force guessing of the password, because under the right circumstances, attempting all possible combinations could take longer than the earth has been in existence. But when it comes to brute forcing a password, you can also set up another barrier – lockouts and notifications. It’s common for people to get a password wrong on any given attempt. They might forget whether a character is “3” or “4”, or maybe the Caps Lock is on. But if someone tries to guess incorrectly 500 times in a few seconds, it’s probably an attack. To really stall brute force attacks, you need a lockout. This means that after some small number of failures (let’s say 4 or 5), the system stops authenticating that user period. You can re-enable authentication for the user after a few minutes (5 to 15, for example). It doesn’t necessarily have to be a permanent lockout. This foils brute force by making it completely infeasible to run through large numbers of guesses. If it takes trillions of years to brute force all possible combinations for a given length of password when a server can run through a billion combinations a second, imagine if it is now forced to deal with 4 or 5 every 15 minutes. Also, it doesn’t hurt to notify the user that something might be up with the account. Maybe they have a disgruntled ex-employee trying to get into a system using a co-worker’s or admin’s account. It also pays to keep a log of such attempts and have notification so your I.T. team can investigate, and perhaps law enforcement as well, if it comes to that.

posted @ 8/29/2008 11:46 AM by DevPrime

Essential utility - visionapp Remote Desktop

Like many developers, I spend quite a bit of my day RDP’ed into some virtual server or other. Even with dual monitors, it can become annoying to flip between sessions.  So then I got a tip about this very nifty utility, and now I couldn’t get along without it.

Made by visionapp, it’s called vRD.  They have a free version, and one that’s $69.00, or slightly more if you want upgrade maintenance & support.  I use the freebie.

You can store your credentials if you want to, categorize your server list in a nice treeview, and the app presents your sessions in a really nice tabbed interface...

Good stuff.

http://www.visionapp.com/141.0.html 

Scroll to the bottom; you’ll see a listing for visionapp Remote Desktop (vRD 1.5) - Freeware.  Registration is required.

Disclaimer: Not affiliated in any way with visionapp.  They don’t even know me.

posted @ 8/27/2008 11:13 PM by Dana Stevens

Changing Table Names in an OR/M

I spent some quality time googling this and even went and asked the nascent Stack Overflow community and didn’t come up with a satisfactory answer. Being the intrepid sort, I opened up a test project and started poking around, compiling information from a number of sources and playing until I got something that worked. For your amusement and/or edification, I’ll document what I found.

What I Want to Do

The basic scenario is that many typical “commodity” web applications use databases to store their information. Since most web hosting services come with a single database but charge extra for additional databases, it is common for web-type products to add identifier text to their table and stored procedure names*. The .Net blog software I sometimes contribute to, Subtext, is an example. Take the table I added to hold tags associated to posts a while back, “subtext_Tag”. Using the “subtext_” prefix means that we won’t run into naming collisions on our tables if someone has a wiki or forum application that also contains a table for tag entities named “Tag”.

The .Net Way

While I was initial open to any .Net OR/M the fact of the matter is that the only one I know anything about is SubSonic. Now I like SubSonic a lot, but their tools are geared towards code generation and I couldn’t find a handle into runtime manipulation of table names (such might exist, but I was unable to find it).

Since I’m even less familiar with the other third party .Net OR/M data tools (like LLBLGen or NHibernate) and nobody on Stack Overflow (who tend to be knowledgeable about these things) spoke up, I decided to check out what it would take to monkey with the table names at runtime using stuff I have actually used. Namely the Entity Framework and LINQ to SQL. It turns out to be possible in either, though I have to admit to being surprised that it is easier in LINQ to SQL than in EF.

My Test Database

To keep things simple, I created a test database. Since I am a highly creative professional, I named it “Test” and created a table there named “TestTable”.

LINQ to SQL

Instantiating a new DataContext object in LINQ to SQL includes a constructor that allows you to feed in a MappingSource derivative. By default, L2S uses an attribute mapping object that pulls the metadata from attributes on your classes—in this case the “Name” property of a TableAttribute.

[Table(Name="dbo.TestTable")]

public partial class TestTable : INotifyPropertyChanging, INotifyPropertyChanged

Since attributes are immutable at runtime, using the default isn’t an option here. Fortunately there’s an XmlMappingSource object that can use an XML file (or fragment) to do what I need. Unfortunately, generating an initial mapping file is a touch cumbersome and requires use of the SQLMetal.exe tool provided with Visual Studio.

Here’s how (after adding a TestLINQ.dbml file and dragging the table onto it—pre-name-change of course):

1. I opened the VS Command Prompt (it’s in a Visual Studio Tools folder in the start menu).
2. Changed the directory to my project.
3. Entered the command “sqlmetal /map:TestLINQ.map /code TestLINQ.dbml”. This generates a TestLINQ.map file.
4. Right-clicked on the generated file in my project and selected “Include in Project”.
5. Set the file’s “Copy to Output Directory” property to “Copy Always”.

The mapping file is pretty simple. The relevant bit is the Name attribute of the Table element:

<Table Name="dbo.test_TestTable" Member="TestTables">

  <Type Name="LINQ.TestTable">

    <Column Name="TestId" Member="TestId" Storage="_TestId" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" AutoSync="OnInsert" />

    <Column Name="TestOne" Member="TestOne" Storage="_TestOne" DbType="VarChar(50)" />

    <Column Name="TestTwo" Member="TestTwo" Storage="_TestTwo" DbType="VarChar(50)" />

  </Type>

</Table>

Make sure the name is what you want it to be and you’re golden. Here’s the code I used to test it out after the name change.

XmlMappingSource source = XmlMappingSource.FromUrl("TestLINQ.map");

using (LINQ.TestLINQDataContext context = new LINQ.TestLINQDataContext(Properties.Settings.Default.TestConnectionString, source))

{

    LINQ.TestTable table = new LINQ.TestTable()

    {

        TestOne = "firstLINQ",

        TestTwo = "secondLINQ"

    };

    context.TestTables.InsertOnSubmit(table);

    context.SubmitChanges();

    table.TestOne = "thirdLINQ";

    context.SubmitChanges();

    context.TestTables.DeleteOnSubmit(table);

    context.SubmitChanges();

}

XmlMappingSource even has a .FromXml() method that will create your map from an Xml fragment string.

Entity Framework

As I mentioned before this one is harder. This is a surprise because EF is ostensibly created to make it easier to keep your object definitions separate from your storage definitions. The reason it isn’t easier is understandable once you realize that EF is made to be highly configurable and thus its definition files are much more complex than the L2S mapping.

The first problem with EF, though, is that the documentation is schizophrenic. Also confusing. That’s because MS rolled the original three configuration files into the .edmx definition file so references on the web imply that those files are easily seen and edited. Even more confusing is that EF actually still uses the .csdl, .ssdl, and .msl files at runtime—it just generates those files from the .edmx and either packs them in the assembly as a resource (by default) or as files in your output directory.

Well, to monkey with the tables at runtime, you have to have access to the configuration files. To do so you need to change the default in the “Metadata Artifact Processing” property of your ConceptualEntityModel and rebuild the project. That’ll put perfectly good .csdl, .ssdl, and .msl files in your output bin directory (You don’t have to leave it at "Copy to Output Directory" once you have saved these files off for your own use and abuse.)

EF did another funky thing by deviating from the norm in what it pulls from the connection string that you feed it. If you look at your EF connection string in app.config (or web.config) you’ll see something like this:

<add name="TestEntities" 

connectionString="metadata=res://*/TestEF.csdl|res://*/TestEF.ssdl|res://*/TestEF.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=Test;Integrated Security=True;MultipleActiveResultSets=True""

providerName="System.Data.EntityClient" />

Notice that there’s a “provider connection string” embedded in the connectionString attribute—that’s the “normal” connection string that tells EF what database to use for storage. Also notice that the metadata property tells EF where to go for those configuration files (in this case, it’s telling EF to look in the assembly for resources TestEF.csdl, TestEF.ssdl and Test.msl).

Armed with this information, I was able to add a set of generated config files to the project stolen from those generated in the output directory. Once there, you have to edit the storage file and the mapping file to use the altered names. The table name used by EF is taken from the Name attribute of the EntitySet element in the .ssdl file. This is unfortunate because the Name attribute is a reference used by things like associations. Which means that you have to make sure you alter all the references to that EntitySet as well (fortunately, these are generally referenced using an EntitySet attribute on the relevant association and thus are relatively easy to find).

<EntitySet Name="test_TestTable" EntityType="TestModel.Store.TestTable" store:Type="Tables" Schema="dbo" />

It’s not necessary to alter the EntityType, though I found that if you alter it consistently across the file it will work if you do.

The mapping configuration in the .msl file just has to be updated so that the objects use the correct EntitySet for storage.

<EntitySetMapping Name="TestTable">

  <EntityTypeMapping TypeName="IsTypeOf(TestEF.TestTable)">

    <MappingFragment StoreEntitySet="test_TestTable">

      <ScalarProperty Name="TestId" ColumnName="TestId" />

      <ScalarProperty Name="TestOne" ColumnName="TestOne" />

      <ScalarProperty Name="TestTwo" ColumnName="TestTwo" />

    </MappingFragment>

  </EntityTypeMapping>

</EntitySetMapping>

Once those changes are made your code will work with the altered table name, though you need to alter the connection string to look for the correct configuration files. Here’s the final code I used to test it out.

string connection = "metadata=TestEF.csdl|TestEF.ssdl|TestEF.msl;provider=System.Data.SqlClient;provider connection string=\"Data Source=localhost;Initial Catalog=Test;Integrated Security=True;MultipleActiveResultSets=True\"";

using (TestEntities entities = new TestEntities(connection))

{

    TestTable table = new TestTable()

    {

        TestOne = "firstEF",

        TestTwo = "secondEF"

    };

    entities.AddToTestTable(table);

    entities.SaveChanges();

    table.TestOne = "thirdEF";

    entities.SaveChanges();

    entities.DeleteObject(table);

    entities.SaveChanges();

}

So Which is Better?

Well, that depends on what you want to accomplish but then, doesn’t it always? For me, the LINQ to SQL solution is much cleaner because I’m simply not going to use all the other goo that the Enterprise Framework includes. Plus, the LINQ to SQL solution can use an XML fragment so I can bury that mapping piece wherever I want to, including in inline code. EF requires a file reference so those files have to be either in the assembly resources or on the file system. EF also allows you to leverage Asp.Net Data Services but that’s a topic for another post entirely...

posted @ 8/27/2008 6:30 PM by Jacob

CR/R! Wrap up

It’s been about a month since I took the challenge to replace ReSharper (R#) with Code Rush/Refactor! Pro (CR/R!). In that time I have adjusted well to CR/R!. There are a number of areas where I am MORE productive. Yep, I said that. There are a few things I miss (So Mark of DevExpress pay attention).

Code Analysis could improve

Code Analysis is a fairly new feature of CR/R! and as one would expect it’s not quite as strong as R#'s (I do expect this to get better, BTW). Sometimes it doesn’t find references to ASP.NET Server Controls from the Code Behind for instance which tends to make its analysis on ASPX CodeBehind files somewhat unpredictable. I also ran into some speed issues with JS code, but I think it was the network that day (because I haven’t had any issues since).

The other thing I love about R# is that not only does it analyze my code, but it gives me a convenient keystroke that helps me resolve the problem without having to leave where I am. CR/R! is building some of this stuff so we’ll have to wait and see what happens.

Embeddings

I still have a few embeddings that I would like to turn off (with no options to do so -- as far as I can tell)... I suspect I need to dig into the XML config files, but am scared to do so.

For the DevExpress Guys to note the main one I want to get rid of is called "Embed Not Parenthesis." What happens is that I’m in a long "if(...)" and I highlight the first "=" of an "==" (because I stupidly set it to "==" and not "!="), when I type "!" it translates my entry to "!(=)=" which would be nice is I had more than 1 character highlighted.

[If you don’t know what they are let me explain them. Basically with CR/R! if you have a section of code highlighted you can easily wrap that selection with say a region by typing CTL+3 (BTW, # = Shift+3 so the sequence makes sense); when you do that a #region/#endregion automagically wraps your selected code and drops you on the line to set the region text. ]

The embeddings in general could really benefit from a different set of key sequences. it’s too easy to highlight a section of code and accidentally type the single character that creates the embedding... I’d prefer a CTL sequence. Yes, I know I can change them myself, but the defaults make the product frustrating for newbies.

Wish List

Beyond what I have already mentioned I really have 1 wish. I want either an alternate set of keystroke shortcuts for things like Embeddings and single character templates [CR/R! has some single character templates that you type like "c{space}" and a class shell automagically appears] that I can set as the default (so choose something other than what has been the standard) or the ability to package up my settings and be able to easily share them...

Yes, Rory, I have thought about contributing an addin for your community project.

Script# Compatibility

BTW, CR/R! works with Script#! Well, I ran into a few minor difficulties, but I could use it with the product which is all I would have asked for. No crashes, and no real warts.

Final words

Well, the good news for the CR/R! crew is that I’m a convert. I waited too long for VS 2008 from R#, and in that time I realized that there is a different place to go to.

Finding that I can refactor all kinds of things (like HTML code and JS code as well as C# and VB code now if it only did Python... just kidding, Mark... I don’t need it) really sealed the deal.

If you are trying out CR/R! you should get the Rory’s latest zip file containing all the community plugins. You should especially install "Refactor_Resolve" from this zip file (You’ll want it!). This is the plugin that was written by Koen Hoefkens. BTW, these plugins I think all run with DXCore, so if you don’t have a license to any kind of Refactoring product then you might want to consider installing DXCore (it’s free) and then installing these plugins... they can make your life a little easier.

posted @ 8/21/2008 1:25 PM by Jay Kimble

Red Gate & Reflector: My Concerns...

Ok, before I start off I want to note that Red Gate is one of our "Friends of TRT," so they show up on just about every page of the site (and would appear in every RSS if I had the time to figure out how to do it). I also want to note that I know that I am breaking a rule with this post and may alienate a vendor, but this needs to be said (and sometimes I can’t resist).

I love Red Gate tools. Their commercial stuff is absolutely awesome, and I mean that. If you don’t own at least their SQL Data/Compare tools, then you should. Their software engineering is without much fault (as far as I have seen). I love how they help the community (hence they are in our "Friends" program).

I was chatting with JP (John Papa) when I caught the news in the latest bulletin from them (it might have been old), and went from casual talk about John’s skin on his blog (see here) to "Crap! Red Gate just bought Reflector..." JP doesn’t necessarily agree with me, but I wanted to at least spit out what I’m bugged by.

Red Gate also owns the PInvoke.net addin for VS2005 (and maybe it now works with VS2008). When you click on the web site to get the addin you are prompted for an email address and are informed that you will be getting ANTS Profiler 3 and Exception Hunter 1 as well... so they bundled 2 trials with a free product... products that you may already have licenses to.

Not only that but every couple days you start getting spammed by their marketing department (it’s one of those... 2 days, 5 days, 1.5 weeks, 3 weeks, and after about a month they finally leave you alone). The bigger problem is that they don’t check their DB to see if you are already a registered licensee of a product (beyond the fact that you went there for a FREE PRODUCT).

So everyone is wondering if .NET Reflector will continue to be free. I know that it will... It will just be bundled with some stuff that you may or may not want... and then you’ll be marketed to for a couple weeks after... That would be my big complaint. I hope that they choose to do otherwise (right now you can still download just .NET Reflector... but the marketing guys haven’t had time yet to figure out what they want to do... so we’ll see what happens).

BTW, I hope I’m wrong about all this ... I really do. Red Gate is a company I really do like (I just don’t always like the way they have handled "free" products in the past)... I hope they continue to have a single download to the free product.

posted @ 8/21/2008 9:22 AM by Jay Kimble

Testability in .Net

Your environment can have a profound effect on how you develop software. The details of what I discuss here have zero practical meaning outside of the .Net world (though you can probably find parallels in other environments). That’s because .Net developers have access to tools that invalidate rules of software design that are fundamentally important elsewhere (before you question whether an environment can effect what is good design, consider the difference between good design in C and, say, Prolog). For .Net, the free availability of a tool like Typemock makes a major design consideration simply disappear—namely, testability. Typemock literally robs the term “testability” of meaning in .Net design considerations. That’s a freedom that should leave other developers gasping in envy.

Typemock’s Magic

I don’t want to be a running commercial for Typemock here (they’re certainly not paying me to say any of this), but it is a truly revolutionary tool and its effect on development in .Net needs to be examined and understood. The thing is that using Typemock means that you can unit test literally any public method of any public class, regardless of any and all internal dependencies that class might have. And you can do so without changing the design and/or architecture of your software at all.

In other words, using Typemock means that everything is testable. Unit testable. Seriously. Everything.

Profound Effect

Stepping into a world where literally everything is testable is like stepping into a world where you wake up at a designated spawn point instead of dying—fundamental considerations about what is risky and what isn’t need to be remapped. Which makes listening to .Net developers discuss testability considerations of various designs a little like listening to World of Warcraft players who are afraid to get too attached to characters that might die—it seems like a lot of effort for something that has little meaning.

Which is why I had such a hard time reading Jeffrey Palermo’s latest blog post entitled “Inversion of Control is NOT about testability”. Since I know Jeffrey Palermo is a .Net developer, my initial response is a big fat “Duh. He must be using Typemock.” Sadly, this is not the case.

Freeeeeeedom!

That’s too bad because there are some very interesting things in that post that get obscured by continually dragging in testability. For one, he gives a good explanation of Inversion of Control accompanied by a discussion of why you might want to use it outside of unit testing. His statements about coupling in particular piqued my interest. He said:

NOTE: There is no such thing as LOOSE COUPLING.  There is coupled, and not coupled.  Either a type is coupled to a type or it is not.  More accurately.  Loose coupling exists much like the concept of "cold".  When we say "close the door, you’ll let the cold out" on a hot day.  Cold doesn’t exist.  Either heat is there or it isn’t.  We use cold to communicate, but it serves as a shortcut for the lack of heat.

Now, he got hold of a bad analogy (because there are degrees of heat—it’s not a binary value—so there is nothing wrong with describing something as “less hot” just as we say "less coupled") and his point is technically wrong (because whether you call it loose, deferred, proxied, or something else, when you are coupled to an interface that a class implements, you have a relationship to that implementing class that is similar enough to coupling that an adjectival modifier is an acceptable descriptor) but the core of his point is still a good one. Tying your class to an interface is a profound change and it is probably a good idea to examine what “loose coupling” means (i.e. how “loose” modifies a coupled relationship).

He later said something I found profound:

In order to do anything useful in software, you must couple. You must couple to something. (emphasis his)

and he later concluded with

You must decide where coupling is appropriate and where it is not.

Importing Designs

Here’s why it’s a tragedy that Jeffrey didn’t make use of his Typemock-granted freedom from testability concerns: that’s all he said about coupling. He wasted so much unnecessary time with things that have no value or meaning in a .Net environment that he didn’t better explore what coupling means and when to mask coupled relationships.

And here’s my wider point: concerns about testability are imported from other environments. .Net folks discuss testability as if it has value in and of itself (because in other environments it does). We forget that testability is no more of a first-order good than quality is. “Testable design” only has value in the things it allows us to do—namely, unit test our classes. If we can unit test our classes as easily no matter what design patterns we choose, then that frees us up to explore other aspects of design choices. It isn’t that <le design du jour> ceases to have value, it’s just that testability is no longer a factor in evaluating its utility.

Those that realize this will have a competitive advantage over those who do not. If I can test no matter my project structure, then I can choose a design that more exactly fits other aspects of my development needs. Which means I can allocate resources more efficiently than someone who has design concerns that don’t fit the actual environment. I can choose <Der Entwurf des Tages> when and where it is actually, immediately useful instead of doing so in order to achieve testability. And efficiency kicks butt in the marketplace.

So, uh, forget all I just said. Spend lots of time making sure your .Net projects are testable. Also: Typemock sucks. Don’t bother going there...

posted @ 8/15/2008 3:58 PM by Jacob

TRT Welcomes Back Dana Stevens

My friend Dana Stevens has decided to rejoin us (he was one of the original TRT members who never got a post up... I said he was just paranoid about being fired, but that’s me <grin />).

He already beat me to the punch and started blogging, so check him out.

Dana is a recovering "Pocket Protector" (Developer) who has sometimes masqueraded (in the past) as a "Black Turtleneck" (Designer). His expertise seems to be eclectic (much like my own), but he is specifically knowledgeable in matters of WCF, Services, and WPF (although he’ll probably be writing on the whole spectrum of software development subjects). In fact he and I often discuss REST versus WCF (I think that WCF can be overkill for what I can do with MS MVC + MVCContrib/RESTFul Services)... but enough of that...

Welcome Dana! Glad to have you back!

posted @ 8/13/2008 11:35 AM by Jay Kimble

SQL Server 2008, Visual Studio 2008 SP1 and Visual Studio 2008 Express

I ran into a bit of weirdness yesterday when trying to install SQL Server 2008.  I have Visual Studio 2008 installed as well as a couple of the Visual Studio 2008 Express products (for testing solutions for the Coding4Fun site and the upcoming book).  I installed Visual Studio 2008 SP1 and all went as planned.  After looking at the Help –> About screens, Visual Studio and all of the Express products showed the proper version tag:  9.030729.1 SP1.  So I figured all the products were updated and good to go.

Next I tried to install SQL Server 2008 and got an error stating Rule “Previous releases of Microsoft Visual Studio 2008” failed.  I re-installed SP1 figuring something had gone wrong, but no dice.  After digging through the SQL Server 2008 install logs I realized what was happening.  The installer was using the HKLM\SOFTWARE\Microsoft\DevDiv\XXX\Servicing\9.0\SP keys to determine if SP1 had been installed and the registry settings were set that it hadn’t been installed for the Express products.

So, I then installed the SP1 versions of all of the Express products (there apparently isn’t an SP1 update for these, you just install the new versions and they are upgraded), tried installing SQL Server 2008 once again, and it worked without a hitch.

In summary, the tip here is that if you have any of the Visual Studio Express products installed, you must install the SP1 versions of those products separately from Visual Studio 2008 SP1 in order to have them properly updated.  The SP1 package for Visual Studio 2008 does not actually update these applications and will block the client-side installation of SQL Server 2008.

posted @ 8/13/2008 5:57 AM by Brian Peek

SQL Quick Tip - Determine data type of column.

Use the very nifty SQL_VARIANT_PROPERTY to determine the data type of a returned column.  

Admittedly, it’s faster to look at the table definition in SSMS.  But this is pretty neat.

DECLARE @TableVar TABLE (MyColumn numeric(18,5)) 

INSERT INTO @TableVar VALUES (5.5) 

SELECT TOP 1 
     MyColumn, 
     SQL_VARIANT_PROPERTY(MyColumn, 'BaseType') AS 'Base_Type', 
     SQL_VARIANT_PROPERTY(MyColumn, 'Precision') AS 'Precision', 
     SQL_VARIANT_PROPERTY(MyColumn, 'Scale') AS 'Scale' 
FROM @TableVar 

posted @ 8/13/2008 12:03 AM by Dana Stevens

Review: Gurock SmartInspect

About a year ago, I was blogging at CodeBetter and I was given a product in hopes that I would review it. In fact I had won a copy of this product in the past. I promised and promised that I would take a look at it, but I never got around to it.

Mainly because I didn’t have a use (or thought I didn’t have a use) for a logging product at the time. Logging isn’t really all that "sexy" and I was trying to dive deep into all kinds of things.

Well, with my day job we ran into a some problems that after I analyzed the errors I realized that I was missing an important piece of the puzzle... So I started thinking about what I might need. Enter that product that I hadn’t had a chance to review...

Logging isn’t "sexy" or is it?

It’s only "sexy" when you NEED it. And when you need it you need something good. SmartInspect is really, really cool, and IMO after finally taking a day with it, I can say it’s also "sexy." It really brings your logging to life.

I’m an ASP.NET guy, so what I need is to be able to track a user through a site and see there path up to the error. SmartInspect allows you to create "sessions" of logs that follow a user via their session. You can also use a default session (if you are using something more single-processed/threaded).

You can colorize different things in the log and can even see the properties of an object that you throw into the log (you simply tell it to log the full object passing just the variable).

The best part for me was it was pretty simple. I did a fairly advanced thing with it in relatively short order (Sessions, logging our SQL calls), and it really wasn’t that much work. The code that you have to inject into your app (yes, you have to inject code into your app) is pretty trivial.

Remote Logging viewing

What I really liked was that the SmartInspect log console feels like VS and is a TCP/IP server which means that you can point an app at a machine to log via TCP/IP. The version that I was given even included source for the logging library (and I think everything else). Yes, you can log to a file and other more traditional log destinations... but the TCP/IP server is so "sexy."

Sold

Anyway, my workplace will be purchasing a copy of it... and it’s a tool you’ll probably need at some point. Here’s the web site (go check it out for yourself) - http://www.gurock.com/products/smartinspect/

BTW, it’s for Delphi, and Java, too.

posted @ 8/12/2008 10:10 AM by Jay Kimble

Writing Better JS Components

Perry (my boss... a developer/manager... he codes and manages) and I have been having a recurring conversation lately. One that keeps bringing to my mind a product that I knew about when I worked for ZAC Catalogs (way back in the day). I would daresay that none of you had even heard of it (although we did pick it up as a result of Xtras carrying it, so maybe a few of you knew about it). I believe it was a called "MFC DataGrid Wizard" or something like that. Anyway what it did was build a custom DataGrid component for you based on selections in a wizard. You selected what features you needed and then it would take it’s full-featured Grid source code (which came with the component) and would dynamically generate a full blown component for you with just the features you needed.

There are two reasons this has become a topic for discussion for me. The first is that we are currently struggling with a set of third party components that a prior developer/manager pushed all over our main site. The components are ones that you have probably heard great things about them and they are pretty cool. The problem is when you shove these components everywhere! We are having ViewState issues among other things... One of the components is a full-featured Grid control (client-side) that while nice we usually only use as a glorified listbox (we use it for selecting an item). As a result I built a specialized DataGrid for our company (one that I’ll be doing a walkthrough on its codebase at the first TUX user group meeting next month)

The other reason is this post from Bertrand LeRoy where he talks about a simple grid for ASP.NET. Here’s my problem with Bertrand’s post. The grid he talks about as being simple really doesn’t sound all that simple to my ears. Let me list a couple features:

• Column drag/drop
• Different column types
• Data Sorting/Paging
• Inline editing

Now mind you these are awesome features if you need them all then you would want to use something like this, but a lot of times what we need is something simpler. You could use the aforementioned grid for this, but the grid will probably still use ViewState (because it needs it maintain state for the paging, sorting, and editing features). It might need several more scripts or <shudder /> it’s script might be 500-1000 lines longer because of the added features.

A Better Way

I have been thinking about a better way to "do" script components. We really need to have a wizard that asks us what we will be needing in the components and then the main script file can be customized (as can the server side code) to remove certain things. It could be done really easy with templates for the script. You need a template for the main file, and additional includes based on features. The server side would work pretty much the same way. I know that no company really wants to give away their source, but even if they were able to do this for script code that would make our lives a lot easier.

posted @ 8/12/2008 8:04 AM by Jay Kimble

New BlueSoleil Driver Fixes BSOD

BlueSoleil has released a new version of their software which supposedly fixes the BSOD problem many people were having.  If you were one of them, download and give it a try!

posted @ 8/7/2008 1:57 AM by Brian Peek

Core Addin Challenge: 2 weeks with CodeRush/Refactor Pro (CR/R!)

[As previously mentioned I have committed to switching from ReSharper (R#) to CR/R!... the end result will be a regular guy’s comparison of the 2.  DISCLAIMER: By no means is this meant to be a slight on R#, but more of me looking at CR/R! a little closer -- I think a number of us took a cursory look at CR/R! and while we found value a surface look doesn’t really give you the full picture... I’m going through the challenges of using CR/R! because it IS different from R# and hopefully I can help folks who are trying to compare between the two and decide which is best for their situation]

Turning the corner (sort of)

Tuesday I turned the corner I thought that there was no coming back (more on that in a second). The thing about CR/R! is that it’s truly a learning experience. CR takes over your environment in such a way that, while it still looks like Visual Studio, you need to re-educate yourself a little to all its nuances. It can actually get in your way (and there have been a couple times with Mark and Rory (and Koen HanHoefkens, the author of the excellent --and free-- CR_Resolve plugin) where I have asked "how do I turn xxx feature off." The most annoying one for me is that I tend to highlight code and start to overwrite with new code... for the most part there are no pains here, except when the character you type is a "(" which is often the character I am typing when changing an "if" statement. What happens is that this embeds your selection in a set of parenthesis.  This was actually easy to turn off... the feature is called "embeddings" which is found in the shortcuts section of the options (there are lots of options with CR/R!). Before I shut them all down I discovered some really rich stuff here... for instance you can highlight code, type "c" and your code is instantly surrounded by a try catch with your cursor setting in the catch block. I still turned off the parenthesis, but I left the rest of them on.

I’ve also started figuring out some of the templates.

I’m still learning here, but the topic is very deep!

BTW, I’ve found that this product enhances your experience while working with ASP.NET HTML, JavaScript, VB, C#, and even Script# (C# variant that creates JS files).

My One hiccup

I have experienced one hiccup over the last several days: PERFORMANCE/MEMORY FOOTPRINT. I’ve had VS crash a few times. I finally think I have the problem figured out (a not so well behaved plug-in I installed... I installed some really old plugins... well they didn’t seem that old).

Currently the only DXCore plugins I have running (besides CR/R!) are CR_RESOLVE, and the "Highlight Current Line" both from the community plugins (mentioned in the last post). I also have turned off the Code Analysis (temporarily).

I am still watching this closely (and am sure that Mark Miller will chime in either personally or publicly with a few more suggestions, but I don’t think he needs to... this lesson should be heeded that you need to be careful which addins you install in VS... they can make things run less than smoothly, and adding a bunch of them all at once makes it even harder to determine where the problem really lies).

posted @ 8/5/2008 3:43 PM by Jay Kimble

Wiimote Smoothboard

I was contacted by Boon Jin Goh recently about his super awesome Wiimote Smoothboard application.  Boon Jin took Johnny Lee’s original Wiimote Whiteboard app and added a ton of functionality.  What was a proof of concept or tech demo is now a fully functional electronic whiteboard capable of being used in a real environment.  Here’s a video showing functionality from the 0.1 version of his app, which has had several updates since.  Definitely give it a try if you’re looking for a very capable electronic whiteboard.  Great job!

Also note that both Johnny Lee and Boon Jin have contributed to our upcoming “Coding4Fun: 10 .NET Programming Projects for Wiimote, YouTube, World of Warcraft, and More” book (yes, the name changed again) with a chapter dedicated to the Wiimote Whiteboard.  This chapter will teach you how to build Johnny’s original whiteboard with the Smoothboard’s spiffy smoothing algorithm added in.

posted @ 8/5/2008 5:22 AM by Brian Peek

101000

Well, this is the geek way to say this... today is the day... at approximately 8:10am est on July 31st, my official age is the equivalent of 1010 or $28 or written in another format : 0x28 (or in VB &h28).

That’s also 50 in octal (which really sucks! I think base 10 looks better than that don’t you think)...

[yep, I’m a geek... you can figure it out... to find that not only am I a geek... but an old one... I wrote all this the night before because tomorrow, I’m afraid that I will be cursed by the early onset of dementia and will have forgotten the whole thing as well as my birthday<grin />]

-----------

PS. I miss you mom.. I wish you were still here on this planet...

posted @ 7/31/2008 5:10 AM by Jay Kimble

Core Addin Challenge: 1 week with CodeRush/Refactor Pro

[UPDATE 8/5: Rory noticed a couple spelling errors in people's names and also noted that I should give Koen HanHoefkens credit for his excellent CR_RESOLVE plugin]

I have survived my first week with CodeRush/Refactor Pro (CR/RP). I have discovered a few things about my development habits:

• I don’t memorize all that many shortcut keystrokes... I tend to look for the "one keystroke to rule them all." Interestingly enough I avoid mouse usage as well
• With the competing produce (R#) I use about 7 features:
  • Improved Intellisense
  • Rename Refactoring (which is also available in VS)
  • Extract Method (also available in VS)
  • Code Analysis
  • Auto-create add using/import
  • File Templates
  • Find Usages

I’m also discovering some things about CR/RP

• I’m discovering that I need to tweak CR/RP’s default settings to avoid some of the "annoyances" (CR/RP can take over at times when you don’t want it to)
• I think If I can get over the hump I am going to find that I’m MORE productive with this thing (although it has been touch and go at times)
• One of my machines seems to run faster than R# and the other not so much (there are different things turned on/off on these machines right now)
• RP provides more refactorings than any other product I have seen!! They even have refactorings for ASP.NET .ASPX files (the html part!!!)

So the "one keystroke to rule them all" for CR/RP is CTL + ~ . Oh yeah, you also need to install the community DXCore addin called -- Refactor_Resolve (which was written by Koen HanHoefkens and you can get from here.. but I would recommend that you get it out of the zip file found here. BTW, thank you Rory Becker for this info). Once you have installed that and get it turned on then Refactor! will give you an option to add usings/imports for your unresolved references.

Oh yeah that community project has a number of nice things you may want to install... like the highlighted line focus.

As I mentioned before you also need to turn on Code Analysis and cut down the size of the little bar at the bottom of the code files, by setting it to 1 file and 0 pixels (it will still show up, but it won’t be as intrusive... your scroll bar will work again). One more thing I believe this feature is a new one (and maybe even a beta one)... it’s not as good as R#'s but from what I understand with their plans it is going to get a lot better (they are going to add over 100 items it can check for and find...)

Additional things I did was I turned off the Smart Brackets and Smart Parentheses and the some of the Smart Paste features features (the auto create properties ones are what I killed... I may kill a few more of the Smart Paste features to get things tweaked out a little better for me).

Summary
All in all things are getting better... Today was a breakthrough day for me (Thank you Rory Becker and Mark Miller)! I think I turned the corner on my experience. I’m think I’m as productive with CR/RP now as I was with R#. I’m only missing 2 things... both of which are livable right now: Find Usages (which I can use the Find References mechanism), and R# File Templates (but CR’s templates are WAY better... so I need to learn a few more of those... I have a number committed to memory already). Just 23 more days to go... but I suspect I'm going to be very comfy before that happens.

posted @ 7/28/2008 10:29 PM by Jay Kimble

DLRScript 0.55 released for Silverlight2 Beta2

[UPDATE: I forgot to add the link to the project - http://www.codeplex.com/dlrscript/]

It took a bit of time for this release. In the end I had to take everything a step back (as well as there are probably a few "mid thoughts" in here as the release of SL2 Beta 2 caught me a bit by surprise... actually the changes to the DLR caught me more by surprise).

The step back is that we no longer get script code lines when there are issues. I’ll try to bring this feature back, but right now if it breaks, you’ll know it via an alert with a .NET error.

Future direction
I need some feedback on this. I’ve been thinking about scrapping any attempt at jscript compatibility and am thinking more about ecma3 support (DLRJScript has an ecma3 mode). The benefit there is that I could start focusing on building a better set of client-side APIs instead of a more compatible one. That said, I’m not sure how qualified I am at coming up with a "better" set of client-side APIs.

I do want some feedback though. Let me know what you think: jkimble-at-gmail.com.

posted @ 7/24/2008 4:12 PM by Jay Kimble

MS MVC Thoughts

[NOTE: I haven’t quite had much of a chance to look at the new Preview 4, so take this as someone nearly informed. I haven’t read about anything in the Preview 4 that changes what I’m going to say. Also, remember that I am the admin/editor of the blog site which is Alt Alt.NET... so testability/mockabilty doesn’t really resonate with me.]

I know it’s shocking that I would have something to weigh in on MS MVC, but I do. For those who don’t know. I took some issue with Ayende’s "leaky abstraction" back in my CodeBetter days (they had to love having me around). BTW, I understood and agreed in some respects, but in others I was less than agreeable. I still think Web Forms are viable and usable, but in some cases the paradigm breaks down, so the need for another paradigm is both welcome and interesting (and before anyone brings up Castle, PixelDragon, or CodeStory MVC frameworks, I have looked at them as well and found them --in general--way too complex to get started with which is not to say that a couple templates could help you guys out...).

Why I’m interested?
Ok, the reason I’m interested is summed up in one word: RIAs. I could have summed that