November, 2007

Larry Osterman's WebLog

Confessions of an Old Fogey
  • Larry Osterman's WebLog

    How to lose customers without really trying...

    • 25 Comments

    Not surprisingly, Valorie and I both do some of our holiday season shopping at ThinkGeek.  But no longer.  Valorie recently placed a substantial order with them, but Instead of processing her order, they sent the following email:

    From: ThinkGeek Customer Service [mailto:custserv@thinkgeek.com]
    Sent: Thursday, November 15, 2007 4:28 AM
    To: <Valorie's Email Address>
    Subject: URGENT - Information Needed to Complete Your ThinkGeek Order

    Hi Valorie,

    Thank you for your recent order with ThinkGeek, <order number>. We would like to process your order as soon as possible, but we need some additional information in order to complete your order.

    To complete your order, we must do a manual billing address verification check.

    If you paid for your order via Paypal, please send us a phone bill or other utility bill showing the same billing address that was entered on your order.

    If you paid for your order via credit card, please send us one of the following:

    - A phone bill or other utility bill showing the same billing address that was entered on your order

    - A credit card statement with your billing address and last four digits of your credit card displayed

    - A copy of your credit card with last four digits displayed AND a copy of a government-issued photo ID, such as a driver's license or passport.

    To send these via e-mail (a scan or legible digital photo) please reply to custserv@thinkgeek.com or via fax (703-839-8611) at your earliest convenience. If you send your documentation as digital images via email, please make sure they total less than 500kb in size or we may not receive your email. We ask that you send this verification within the next two weeks, or your order may be canceled. Also, we are unable to accept billing address verification from customers over the phone. We must receive the requested documentation before your order can be processed and shipped out.

    For the security-minded among you, we are able to accept PGP-encrypted emails. It is not mandatory to encrypt your response, so if you have no idea what we're talking about, don't sweat it. Further information, including our public key and fingerprint, can be found at the following

    link:

    http://www.thinkgeek.com/help/encryption.shtml

    At ThinkGeek we take your security and privacy very seriously. We hope you understand that when we have to take extra security measures such as this, we do it to protect you as well as ThinkGeek.

    We apologize for any inconvenience this may cause, and we appreciate your understanding. If you have any questions, please feel free to email or call us at the number below.

    Thanks-

    ThinkGeek Customer Service

    1-888-433-5788 (phone)

    1-703-839-8611 (fax)

    Wow.  We've ordered from them in the past (and placed other large orders with them), but we've never seen anything as outrageous as this.  They're asking for exactly the kind information that would be necessary to perpetuate an identity theft of Valorie's identity, and they're holding our order hostage if we don't comply.

    What was worse is that their order form didn't even ask for the CVE code on the back of the credit card (the one that's not imprinted).  So not only didn't they follow the "standard" practices that most e-commerce sites follow when dealing with credit cards, but they felt it was necessary for us to provide exactly the kind of information that an identity thief would ask for.

    Valorie contacted them to let them know how she felt about it, and their response was:

    Thank you for your recent ThinkGeek order. Sometimes, when an order is placed with a discrepancy between the billing and the shipping addresses, or with a billing address outside the US, or the order is above a certain value, our ordering system will flag the transaction. In these circumstances, we request physical documentation of the billing address on the order in question, to make sure that the order has been placed by the account holder. At ThinkGeek we take your security and privacy very seriously. We hope you understand that when we have to take extra security measures such as this, we do it to protect you as well as ThinkGeek.
    Unfortunately, without this documentation, we are unable to complete the processing of your order. If we do not receive the requested documentation within two weeks of your initial order date, your order will automatically be cancelled. If you can't provide documentation of the billing address on your order, you will need to cancel your current order and reorder using the proper billing address for your credit card. Once we receive and process your documentation, you should not need to provide it on subsequent orders. Please let us know if you have any further questions.

    The good news is that we have absolutely no problems with them canceling the order, and we're never going to do business with them again.  There are plenty of other retailers out there that sell the same stuff that ThinkGeek does who are willing to accept our business without being offensive about it.

     

    Edit to add:  Think Geek responded to our issues, their latest response can be found here.

  • Larry Osterman's WebLog

    Chris Pirillo's annoyed by the Windows Firewall prompt

    • 63 Comments

    Yesterday, Chris Pirillo made a comment in one of his posts:

    And if you think you’re already completely protected in Windows with its default tools, think again. This morning, after months of regular Firefox use, I get this security warning from the Windows Vista Firewall. Again, this was far from the first time I had used Firefox on this installation of Windows. Not only is the dialog ambiguous, it’s here too late.

    I replied in a comment on his blog:

    The reason that the Windows firewall hasn’t warned you about FF’s accessing the net is that up until this morning, all of it’s attempts have been outbound. But for some reason, this morning, it decided that it wanted to receive data from the internet.

    The firewall is doing exactly what it’s supposed to do - it’s stopping FF from listening for an inbound connection (which a web browser probably shouldn’t do) and it’s asking you if it’s ok.

    Why has your copy of firefox suddenly decided to start receiving data over the net when you didn’t ask it to?

    Chris responded in email:

    Because I started to play XM Radio?  *shrug*

    My response to him (which I realized could be a post in itself - for some reason, whenever I respond to Chris in email, I end up writing many hundred word essays):

    Could be - so in this case, the firewall is telling you (correctly) exactly what happened.

    That's what firewalls do.

    Firefox HAS the ability to open the ports it needs when it installs (as does whatever plugin you're using to play XM radio (I documented the APIs for doing that on my blog about 3 years ago, the current versions of the APIs are easier to use than the ones I used)), but for whatever reason it CHOSE not to do so and instead decided that the correct user experience was to prompt the user when downloading.

    This was a choice made by the developers of Firefox and/or the developer of XM radio plugin - either by design, ignorance, schedule pressure or just plain laziness, I honestly don't know (btw, if you're using the WMP FF plugin to play from XM, my comment still stands - I don't know if this was a conscious decision or not).

    Blaming the firewall (or Vista) for this is pointless (with a caveat below). 

     

    The point of the firewall is to alert you that an application is using the internet in a way that's unexpected and ask you if it makes sense. You, the user, know that you've started playing audio from XM, so you, the user expect that it's reasonable that Firefox start receiving traffic from the internet. But the firewall can't know what you did (and if it was able to figure it out, the system would be so hideously slow that you'd be ranting on and on about how performance sucks).

    Every time someone opens an inbound port in the firewall, they add another opportunity for malware to attack their system. The firewall is just letting the user know about it. And maybe, just maybe, the behavior that's being described might get the user to realize that malware has infected their machine and they'll repair it.

    In your case, the system was doing you a favor. It was a false positive, yes, but that's because you're a reasonably intelligent person. My wife does ad-hoc tech support for a friend who isn't, and the anti-malware stuff in Windows (particularly Windows Defender) has saved the friends bacon at least three times this year alone.

     

    On the other hand, you DO have a valid point: The dialog that was displayed by the firewall didn't give you enough information about what was happening.  I believe that this is because you were operating under the belief that the Windows firewall was both an inbound and outbound firewall.  The Windows Vista firewall  IS both, but by default it's set to allow all outbound connections (you need to configure it to block outbound connections).  If you were operating under the impression that it was an outbound firewall, you'd expect it to prompt for outbound connections.

    People HATE outbound firewalls because of the exact same reason you're complaining - they constantly ask people "Are you sure you want to do that?" (Yes, dagnabbit, I WANT to let Firefox access the internet, are you stupid or something?).

    IMHO outbound firewalls are 100% security theater[1][2]. They provide absolutely no value to customers. This has been shown time and time again (remember my comment above about applications being able to punch holes in the firewall? Malware can do the exact same thing). The only thing an outbound firewall does is piss off customers. If the Windows firewall was enabled to block outbound connections by default, I guarantee you that within minutes of that release, the malware authors would simply add code to their tools to disable it.  Even if you were to somehow figure out how to block the malware from opening up outbound ports[3], the malware will simply hijack a process running in the context of the user that's allowed to access the web. Say... Firefox. This isn't a windows specific issue, btw - every other OS available has exactly the same issues (malware being able to inject itself into processes running in the same security context as the user running the malware).

    Inbound firewalls have very real security value, as do external dedicated firewalls. I honestly believe that the main reason you've NOT seen any internet worms since 2002 is simply because XP SP2 enabled the firewall by default. There certainly have been vulnerabilities found in Windows and other products that had the ability to be turned into a worm - the fact that nobody has managed to successfully weaponize them is a testament to the excellent work done in XP SP2.

     

    [1] I'm slightly overexaggerating here - there is one way in which outbound firewalls provide some level of value, and that's as a defense-in-depth measure (like ASLR or heap randomization). For instance, in Vista, every built-in service (and 3rd party services if they want to take the time to opt-in) defines a set of rules which describes the networking behaviors of the service (I accept inbound connections on UDP from port <foo>, and make outbound connections to port <bar>). The firewall is pre-configured with those rules and will prevent any access to the network from those services. The outbound firewall rules make it much harder for a piece of malware to make outbound connections (especially if the service is running in a restricted account like NetworkService or LocalService). It is important to realize this is JUST Defense-in-Depth measure and CAN be worked around (like all other defense-in-depth measures). 

    [2] Others disagree with me on this point - for example, Thomas Ptacek over at Matasano wrote just yesterday: "Outbound filtering is more valuable than inbound filtering; it catches “phone-home” malware. It’s not that hard to implement, and I’m surprised Leopard doesn’t do it."  And he's right, until the "phone-home" malware decides to turn off the firewall. Not surprisingly, I also disagree with him on the value of inbound filtering.

    [3] I'm not sure how you do that while still allowing the user to open up ports - functionality being undocumented has never stopped malware authors.

  • Larry Osterman's WebLog

    Think Geek Responds

    • 14 Comments

    Valorie just received the following email from Think Geek (in response to our previous issue with them):

    From: Caroline Offutt [mailto:<email address at thinkgeek.com>]
    Sent: Sunday, November 18, 2007 7:05 PM
    To: <valorie's email address>
    Cc: Rob Patak

    Subject: Issues with ThinkGeek order

    Ms. Osterman,

    I would like to apologize for all of ThinkGeek for the fraud issues you had with your recent order and the response you received from our customer service department. We are about to roll out our new fraud prevention program including implementing CVN this week (it is unfortunate that we didn't roll it out two weeks earlier). With our new program, most orders, like yours, will process without a hitch and we hope that only those orders that are truly fraud will be stopped. If you are interested, I would be happy to go into more detail of why your order was stopped and how we are changing the process.

    If you decide to have your ThinkGeek order# <order number>processed, we would like to take $50 off it. Or if you rather, we will email you a $50 gift certificate to use towards a future order. Please let me know how your would like to proceed. Also, feel free to contact me directly if there is ever anything we can do for you. Because of the holidays, I will be at our warehouse much of the next month and not always available, so please contact Robert Patak, Customer Service Supervisor, if you are unable to reach me (<email address>@thinkgeek.com, <phone number>).

    Sincerely,
    Caroline Offutt

    --

    Caroline Offutt, VP & GM

    ThinkGeek, Inc.

    Tel: <phone number>| Fax: <phone number>

     

    I'm glad to see that they realized that they have an issue - I don't know if they found my earlier whine, or if their internal processes picked up on the issue, but I'm very happy that they're attempting to address our annoyance.

    We've still not decided what to do about this issue yet, but I do need to acknowledge that they are listening and are trying to resolve the issue.  Two points to Think Geek.

  • Larry Osterman's WebLog

    When you're analyzing the strength of a password, make sure you know what's done with it.

    • 20 Comments

    Every once in a while, I hear someone making comments about the strength of things like long passwords.

    For example, if you have a 255 character password that just uses the 26 roman upper and lower case letters, plus the numeric digits.  That means that your password has 62^255 possible values, if you can try a million million passwords per second, the time required would exceed the heat death of the universe.

     

    Wow, that's cool - it means that you can never break my password if I use a long enough password.

     

    Except...

    The odds are very good that something in the system's going to take your password and apply a one-way hash to that password - after all, it wouldn't do to keep that password lying around in clear text where an attacker could see it.  But the instant you take a hash of a secret, the strength of the secret degrades to the strength of the hash.

    It's another example of the pigeonhole principle in practice - if you put N+M items into N slots, you're going to have some slots with more than one entry.  The pigeonhole principle applies in this case as well.

     

    In other words, if the password database that holds your password uses a hash algorithm like SHA-1, your 62^255 possible character password just got reduced in strength to a 256^20 possible value hash[1]. That means that any analysis that you've done on your password doesn't matter, because all an attacker needs to do is to find a different password that hashes to the same value as your password and they've broken your password.  Since your password strength exceeds the strength of the hash code, you know that there MUST be a collision with a weaker password.

     

    The bottom line is that when you're calculating the strength of a  password, it's important that you understand what your password looks like to an attacker.  If your password is saved as an SHA-1 or MD5 hash, that's the true maximum strength of your password.

     

    [1]To be fair, 256^20 is something like 1.4E48, so even if you could still try a million million passwords per second, you're still looking at something like a million million years to brute force that database, but 256^20 is still far less than 62^255.

  • Larry Osterman's WebLog

    Adding AutoComplete to your edit controls

    • 25 Comments

    For whatever reason, most of the toy applications I tend to write seem to end up being dialog based applications.  I'm not 100% sure why, it probably has to do with the fact that the dialog box editor makes it really easy to drop controls on a page.

     

    One of the things I often have to do is to specify a filename to the toy application.  To do that, I usually add an edit control to display the filename and a "Browse..." button which brings up the common file browser control.  Many people find it awkward to use the common file browser to locate files, so they often try typing into the edit control.

    One of the really easy "nice touches" that you can specify to help with navigation is to add autocompletion support to the edit control.  Fortunately, the Windows shell provides a really handy mechanism to do this in the SHAutoComplete function. 

    Adding autocomplete support is literally as easy as adding:

    SHAutoComplete(hWndEdit, SHACF_FILESYSTEM);\

    to your code.

    It turns out that the shell has a fairly extensive autocomplete mechanism that allows you to customize this facility to a great deal (you can provide your own lists of elements, merge lists from multiple sources, etc).

     

    For me, I almost always end up falling back to the old standby of SHAutoComplete - it's trivial to add it, and it adds a nice touch to your applications.

  • Larry Osterman's WebLog

    The Shell used to get all the cool APIs :)

    • 5 Comments

    After I posted my article on the SHAutoComplete, I mentioned it to one of my co-workers.  His response "I'm not surprised - The shell gets all the cool APIs".   And they do.

    For instance, my "new favorite" Win32 API: RegGetValue began it's life as the SHRegGetValue function.  But increasingly, many of the cool shell APIs are moving out of the shell, and that's a good thing.

    Over the past couple of releases of Windows, there have been a great number of "shell" helper APIs that have gotten "promoted" out of the shell and transformed into Win32 core APIs.  One of the reasons for that has been the ongoing Architectural Layering effort initiated by some of the teams in the Core OS Division.  I wrote about this layering process a couple of years ago, the MinWin effort that was discussed recently is another benefit of the archlayer work.

    The SHRegGetValue API was one of the APIs flagged by the layering issue as being more appropriate for core OS functionality - the analysis done by the layering team showed that a number of low level components in operating system were calling into the shell DLLs because the shell helper functions provided some convenient functionality that wasn't present in the lower layers.

    As a result, a number of shell APIs were recreated as kernel32 APIs.  You can see some of them on the "What's New in Windows Vista" page on MSDN.  They include:

    There are undoubtedly others that have been migrated over time, these were just a few that I picked up in a couple of minutes of searching.

    In general, this is a good thing for both the shell and the core OS teams.  The more applications clients that move away from the shell APIs and into the kernel32 equivalents, the better it will be for the entire ecosystem.

    This is another example of how a relatively small change to an application (removing a dependency on shlwapi32.dll) can have significant benefits to the application - as I've mentioned in previous posts, each DLL you load consumes 4 private pages and takes between 500 thousand and a million cycles to load.  If you can remove that dependency, your application will thus load faster.

  • Larry Osterman's WebLog

    My son is SUCH a geek (in a good way) :)

    • 23 Comments

    Back when Daniel was in 5th grade, his teacher Bob Whittemore taught a unit that he called "Patterns and Functions".  The unit used sequences of numbers to introduce the students to the concept of polynomials and polynomial equations.

     

    The core of the patterns and functions unit involves a mechanism that can be used to find the equation for any polynomial from the series generated by the polynomial.

    For example, if you have the sequence:

    1 79
    2 561
    3 2279
    4 6445
    5 14679
    6 29009

    you can find the polynomial that generated this sequence by subtracting item <n> from item <n+1>.  In this case, you get:

    1 79  
    2 561 482
    3 2279 1718
    4 6445 4166
    5 14679 8234
    6 29009 14330

    you repeat until the differences stabilize.  Eventually you'll get something like:

    1 79        
    2 561 482      
    3 2279 1718 1236    
    4 6445 4166 2448 1212  
    5 14679 8234 4068 1620 408
    6 29009 14330 4096 4028 408

    The sequence stabilizes after n iterations (in this case 4), that tells us the highest degree of the polynomial.

    The coefficient of the x^n term is the stabilized difference divided by n! (factorial).  In this case, the difference is 408, 408 / 4! = 17, which in fact is the first term of the equation.

    Now that you know the highest order term, you go back to your original sequence of numbers and subtract the highest order term (17x^4th in this case) from the number which will give you a new series (this time you know it will stabilize after 3 iterations).  Wash, rinse and repeat <n> times (one for each of the exponential terms), and you'll figure out that the original equation was: 17x^4+32*x^3+x^2+<something>.  To find the value of <something>, simply solve the original equation for x=1 and you'll get 17+32+1=50.  79-50 = 29, so <something> = 29 and thus the original equation is:17x^4+32*x^3+x^2+29.

    Anyway, Mr. Whittemore never knew the official name for this technique, he just knew it worked.  Daniel's been trying to figure out what the "official" name of this was for years, he's asked every one of his math teachers over the years and none of them have ever known the answer.

    Yesterday, he asked his math teacher from last year about it and he finally got the answer :)  It turns out that this is officially called the "Method of Successive Differences".  Live search points to a cached page (the original apparently isn't live).

    I retried my search using google, and it turns out that Google has scanned a book from 1834 called "An Elementary treatise on algebra, theoretical and practical" which spells out the mechanism in detail.

    So why did I entitle this post "My son is SUCH a geek (in a good way)"?

    When Valorie picked Daniel up from school, he was bubbling that he'd found this information.  He insisted that she drive to his old school right away so he could find Mr. Whittemore and let him know that he'd finally learned the official name for what Mr. Whittemore's been teaching for years.  As Valorie drove away from the school, Daniel opened up the car window and shouted out to anyone who would listen: "I know what Patterns and Functions is called!".  I don't know if I've ever seen him more excited.

    So yeah, my son is SUCH a geek :).

    And I love him :).

     

    Edit: Fixed typo in the actual equation.  Thanks Ben for checking my math.

  • Larry Osterman's WebLog

    So Amazon brought out this "Kindle" thingy... But I have one question for them...

    • 14 Comments

    Amazon just brought out a new eBook reader called "Kindle".  It looks pretty cool, but I have one question:  "Where can I go to try one of these out before I fork over $399 for one of them?"

     

    I have a real problem with buying a new technology item (especially one where the form factor is as critical as an eBook reader) without actually having one in my hand before I purchase it.  So I'm sitting here wondering which retailers carry the Kindle.  For some strange reason, I can't seem to find it on Amazon's web site :).

    Somehow I think that once again, I'm going to be waiting until one of my co-workers buys one before I can play with it.

     

    See, there ARE some things that brick&mortar stores do better than electronic retailers - they let you touch the merchandise before you buy it.

  • Larry Osterman's WebLog

    I don't know if I should be honored or ashamed :)

    • 6 Comments

    Yesterday, we had the weekly security contacts meeting for the WEX division.  At those meetings, they sometimes give out awards for people who have gone above and beyond the call of duty.

     

    Much to my surprise, I won one of the awards!

    Picture of Bobble-Butt Horse Trophy

    You can't read the text, but it says "Most M1 TM's Reviewed & Rejected - Larry Osterman".  You also can't see it, but the hind end of the horse is a bobblehead :).

    I'm not sure if getting the award is really good thing though - the award was given because of all the threat model reviewers in the WX division, I rejected the highest percentage of the threat models I reviewed.  My dilemma is that I don't know if it's because I was being such a tough reviewer (personally I don't think I was) or if it's because the threat models I reviewed were were crappy :).  Given that I only reviewed threat models from my group, and since I helped most the teams in my group create those threat models, the latter possibility concerns me a great deal :).

     

    But heck, ultimately it doesn't matter - the threat models I reviewed have all been fixed and are now of high quality, but I'm still trying to figure out if I was rewarded for my effort or my team was diss'ed :)

     

     

    For those that obsess about other stuff that can be seen on people's desks, you can see my trusty HP 16C calculator, my Sensa pen, some random audio cables, my "Microsoft Tiger '94" pin (from my short stint in research) and my spiral bound notebook.

  • Larry Osterman's WebLog

    Hanselminutes

    • 6 Comments

    A couple of weeks ago, Scott Hanselman stopped by my office, and we chatted for almost an hour for his Hanselminutes  podcast.

     

    On Monday, he posted the interview - it's mostly me rambling on about security and other stuff, but my ego requires that I mention it :)

  • Larry Osterman's WebLog

    Analog to Digital Conversion

    • 7 Comments

    Steve Rowe (test lead on the sound team) points to a great article from Ars Technica on D2A:

    If you want digital audio in a computer, you have to get it from somewhere.  Usually that means taking analog sound out of the air and turning it into the bits that a computer can understand.  Ars Technica gives us another installment of the AudioFile. This one covers the subject of Analog to Digital Conversion.

    Well worth reading.

Page 1 of 1 (11 items)