Are password textboxes really secure?

You know, the control on the form that displays some character over and over instead of displaying the text behind.

Let's create a simple demo. i will have a WinForms application with a single form that hosts a single TextBox. I'll set TextBox.PasswordChar to asterisk (*). That's all I need to create the demo. After running the application and typing word tubo into the text box I'll see something like this:

You would think that text is protected and nobody can get to it even if he has access to the computer, right? Wrong. Due to the nature of the Windows controls one can always inspect its properties through their handle. A nice tool that lets you do inspection like this is Spy++ that comes with Visual Studio - you'll find it in Visual Studio Tools subfolder in start menu. Run Spy++, click on Search/Find Window... menu entry. Drag the marker shown in picture bellow

over the our protected text box and this window will appear:

Text is clearly visible now. And you can even set the value and do the same with other supported properties. And of course this feature isn't limited to TextBox control.

Magic? No, just the way Windows works. Well, until now. Since Vista is introducing new UI system called WPF (which runs on Windows XP, too) I think it won't be that easy anymore to get to the control's content or even impossible due to entirely different system. I guess that makes WPF automatically more secure.

WPF/E at work

I know I am bit late, but nevertheless, if you want to see a nice and cool example of WPF/E driven web pages then you must navigate to www.windowsvista.si. Even if the page(s) are in Slovene you should understand much of what you'll see.

NOTE: WPF/E February CTP is used. If you don't have it installed then click on the top icon on the front page to install it. After you have WPF/E on local machine you should click on one of the two bottom icons. Enjoy.

iTunes is trying to destroy my RAID 10 running on Vista x86

It all started to happen when I tried to convert a large video to iPod format within iTunes. Since the conversion takes time I left the computer for a while. When I returned I got "Unable to boot screen" because Vista x86 bluescreened. The frightening fact was that it couldn't boot even though I am on RAID 10 (controlled by Intel ICH8R). Next I went to check into the RAID diagnostics utility and saw an even more frightening fact: 3 out of 4 drives were marked red saying "Failure". Fortunately the utility offered to recover RAID array and marked all but one drive as Normal. So there was still hope. I restarted and I could boot to Vista. As soon as I logged in Intel Matrix Storage Console warned me that my RAID array was degraded (since one of the volumes wasn't operational this info was correct). So I marked the fourth drive as normal as the RAID array was rebuilt in a couple of hours or so. Good for me, everything was working again and nothing was lost.

Now it was time to investigate the cause of this hard crash - I mean taking out 3 of 4 disks isn't just a normal blue screen and if there is a system problem I am in trouble. My first suspect was my Intel E6600 Dual Core CPU. Last thing I did to my computer before crash was to start a lengthy conversion that utilizes 100% of one CPU core (50% of entire CPU). The theory was that it could warm up too much during the conversion and when a CPU is overheating odd things happen. I crated a simple .net application that does an endless loop and run it twice so both cores would be pushed to the limit. Before that I've installed and run SpeedFan utility (one of the few sensor reading applications that work on Vista) that reads the temperature info from motherboard/CPU. I saw that when CPU is pushed to the limit the temperature of the cores raises to 53C/51C. The numbers don't look too high for me - before running Intel I was running an Athlon 2800+ that could reach 70C without problems - that was one hot CPU hard to cool. Back to my investigation. If my CPU crashed because of that relatively low temperatures it would mean that CPU is probably faulty and I would have to change it - I guess I would loose almost a week. Ouch. But this wasn't it. Vista was happily running without and problem for half an hour. Good for me. What was then? As a good programmer I tried to recreate the situation - I fired up iTunes and started conversion again - after some minutes it bluescreened again with similar RAID problems - disks were failing. That made iTunes the prime suspect that I would torture for a confession if I had to. I mean it can't be coincidence. I figured out that doing a conversion does something bad, very bad. Because I don't want to debug iTunes I decided to avoid the conversion feature and do conversions using other software available - Videora iPod Converter is an excellent choice, furthermore is free. Of course there were no problems converting video using Videora stuff. However, when I tried to update my iPod (again using iTunes) with converted video (that means just updating iPod data) Vista bluescreened again having a bunch of failed disks.

For now I decided to avoid using iTunes at all costs since I don't have time to rebuild my RAID array for couple of hours per crash through each day. I don't know what the exact problem is but it only manifests when iTunes is doing something (i.e. updating iPod). OK, I know that Apple doesn't recommend running iTunes on Vista for now, but this problem is just too much - that an application kills RAID disks isn't acceptable for Apple (destroying RAID), Intel (perhaps there is something wrong with RAID drivers?) and [MS] (letting iTunes destroy RAID).

The bottom line is beware of iTunes on Vista.

UPDATE: Although I managed to rebuild RAID volume, NTFS was damaged beyond repair. chkdsk just gives up on errors and all I can do is to login in safe mode. Thus I'll have to reinstall Vista today. Oh well.

UPDATE 2: A reader (in a comment bellow) reported that Apple Quicktime causes the same problem. Consider yourself warned.

UPDATE 3 (18.4.): I contacted Intel technical support and they say it certainly isn't their fault. The only explanation from them: it happens only with iTunes. I doubt that they bothered checking at all. But how can they say that it isn't their fault as their driver/controller (the last line between disk and other hw) should protect the integritiy of RAID array and shouldn't let any application destroying it. I will try to issue a PSS request to [MS] asap. I would ask Apple, too, but I don't have any contact e-mail...

UPDATE 4 (26.4.) One of the readers might have found the answer and solution to the problem. See for yourself here. Note that I didn't tested it nor I can confirm it or anything. However, it seems that he is on the right track.

UPDATE 5 (7.5.) A reader is reporting that it happens on opteron 170 in a DFI Lanparty nF4, too. This info sort of moves finger away from Intel to [MS] and Apple.

UPDATE 6 (11.5.) A breakthrough: Intel acknowledges the problem.

Pitfalls of antivirus programs

One has to be careful when using an antivirus application that protects computer in real time (scans files when one opens them). Here is what happened. I am working on a project for a customer of mine. For source file control we use Visual SourceSafe over VPN. I won't discuss further whether this is an ideal combination... It actually performs good enough even though the line is relatively slow. However, one day it became dead slow. By dead slow I mean half an hour to open an project and 2+ hours to get latest version. I immediately suspected Internet provider and transfer speed over Internet. Yet, this wasn't it - it was working normally on another computer of mine.

So I start thinking what did change on my computer in last week or so. After exactly 5s of deep thinking I had a revelation - I installed an antivirus system a week or so ago. Combine it with VSS over VPN and you have an unresponsive VSS client. However, the problem is not within this particular antivirus application. The problem is in the VSS itself. VSS is just a file server, meaning that everything is done on the client - actually there is no such thing as VSS server (there is some thin layer when using VSS2005 over Internet). And knowing that VSS usually produces a myriad of small files I immediately figured it out what's going on - VSS client has to check a ton of these files and each file is checked by antivirus application in real time - thus totally killing the performance (multiplying * x access on each file over VPN).

The solution was simple - I disabled real time monitor for network files and VSS started to perform normally again.