June 2005 Archives
Since SQL Server 2005 now permits administrators to force (coerce?) users to set (and periodically reset) passwords, is there a way to change the Windows strong password schema to a custom design?
Sure, I don’t recommend administrators grant people login accounts—I suggest these be assigned to job roles like “AdminClerk2” or “JuniorJanitor” or “PointyHairedBoss”. In any case, studies have shown that the Microsoft-style strong passwords are tough to remember. While a young person with a high IQ can remember a random set of numbers, case-sensitive letters and punctuation, those users with average IQ or those of advancing age (like me), find it tough to remember where we put the car keys, much less a complex password. So… we write it on a piece of paper where it won’t be missed and hope for the grace of honest people.
An alternative for us challenged folks of diminishing capacities is to use another (and it turns out more/just as) secure password schema. Simply concatenating two or more words together with punctuation works just as well. For example, the password “City.Dog!” is easy to remember and virtually as secure as the Microsoft style. Add a digit or two and it's even stronger.
Is there a way to program Windows domain controllers to use this or some other custom alternative schema? It seems to me that code hackers who did not know that a company was using a non-standard (non-Microsoft) password schema would be no better off... Comments?
(Originally posted 6/23/2005)
This entry was resurected from my old blog... it's a keeper.
The Microsoft Developers have already begun the process of picking up the shards and shattered pieces of their Whidbey implementation that were sheared off as the product was being stuffed into the box. Some of these feature fragments will be retooled and redesigned to be implemented in the next version of Visual Studio dubbed “Orcas“ designed to support Longhorn (the next version of Windows based on the .NET Framework). It's time for all of us to encourage Microsoft to fix old problems, address old issues and make ADO.NET better suited to develop our applications. To get us started I propose the following...
While you are at it, let me add another one -
"Full Backups of a hot & live database"
1) Focus on getting what you have already invented working better rather than inventing more classes to do things differently—making the existing classes redundant. Developers want clear choices not a Swiss army knife with 70 blades just to open an envelope.
2) Stop deprecating established classes like the DataAdapter Configuration Wizard. This just causes confusion and needless thrashing. You’re trying to get people to adopt the product and continue to leverage their existing skills. Ripping out or hiding familiar objects is counter-productive.
3) Add the ability to right click in the editor IDE and “Insert SQL”. This would launch the query builder and return a properly formatted query string.
4) Provide an ability to interactively construct (code-generate) Parameters collections from selected ad hoc or stored-procedure queries. You had this in 2003, but dropped it in Whidbey. You could drag a stored procedure from the server explorer and drop it on a form. This would generate the Parameters collection code.
5) Make it crystal clear how to indicate that a Parameter object is to use the server-side default value (this might only require a good doc topic)
6) Figure out how to generate these Parameter collections and get the direction correct. There are still cases where code generators use Input/Output for Output parameters.
7) Get server-side cursors working again. Yes, this is not generally needed by the masses, but there are still many situations where this “connected” approach makes abundant sense. We’ve seen that connected architectures work fine and can be more productive (and easier to write) than disconnected in many scenarios. Forcing everyone to use disconnected or ASP architectures is not helping adoption rates. Consider that the default behavior in
8) When you think about scalability and how it impacts your implementations, consider that the majority by far of applications don’t have to scale beyond a few dozen to a few hundred users. It’s only in the largest companies that these approaches break down. Forcing developers to use an architecture that scales from 50 to 50,000 clients does not make sense if all they need to support are 200 clients.
9) Make Open, Fill and Load asynchronous-capable. Saying that this can be done with a BackgroundWorker thread is simple to say, harder for some to do.
10) Provide progress events in Fill and Load to preclude the need to code these asynchronously.
11) Add more documentation on performance tuning that emphasizes server-side processing. That is, moving bulk data to the client for processing and shipping it back does not make sense if the query engine can perform these functions in situ.
12) Provide a better/smarter/more easily configurable CommandBuilder. We need to be able to set the same Update Criteria options that we could use in
13) Start writing the doc so it includes Visual Basic examples, but not necessarily just translated from C#. Visual Basic’s approach to events, object disposal and other issues is different—especially for Visual Basic 6.0 developers. Yes, Visual Basic has Using, but adding Using to a Visual Basic .NET example because C# has it does not help Visual Basic 6.0 developers understand how to convert their code.
14) Document scenarios for individual data-bound controls like the Visual Basic 6.0 MSHFlexGrid and show specifically how to convert to the DataGridView. Include similar topics for other typical custom controls and show how these can be converted on a more granular level.
15) Get Exception handling under control. I’m not sure where you are at this point, but as it is, it’s broken—there are still too many catch-all exceptions being returned. “Stuff happened” is not a suitable exception message…
16) Find a way to build a “VLW” (very light weight) SQL query engine (like SQL CE) for use on the desktop for applications that need to store and retrieve information from smaller databases. While developers can persist data with XML it’s harder to use traditional SELECTs and relational approaches to the rehydrated DataTables.
17) Think about ways to make replication foolproof. Your goal should be to make replication and database synchronization work as well and as deterministically as Outlook syncing with Exchange.
18) Now that the CommandBuilder has been reverted back to
UPDATE: July 4: 2005 Nope, the rather complex trigger approach did not work. It seems for one reason or another the trigger never fired. It also failed to do one simple thing: rollback the insert transaction.
I did some additional research and it seems the Captcha does not stop anybody but those wishing to post comments. After studying the inbound spam I discovered something that should stop them (for now). I'll share that with anyone that I know but I won't share it with the web--that's where the spammers live.
I added some code to my .TEXT blog to prevent the spammers from adding comments. Be sure to send me mail (you know my email address) if you have trouble logging comments.
I just tested it and it seems to be working. Basically, the code uses the “trigger“ approach to filter inbound comments.
Nope, the trigger approach shut down the spammers that had many URLs in the text, but not the others. I had to add a control that capture the scrambled text in another attempt to keep out the creeps and cretins.
I just got back from the DevTeach conference in
Getting to the conference was not too bad but flying back was a royal PITA. We took a wide-body flight from
Do you know about good tutorials or books about this in SQL 2005?
As far as Lennie's question goes, if Sony made a car I'd buy it in a second and I'd buy ANYTHING made by Toyota other than those really ugly Scion's. Motorola is a great company in so many ways and has tremendous quality in many areas - problem is when they get out of there 6 Sigma boundary - they produce nightmares as Bill can attest to.