Slashdot Mirror
More Headaches from Vista Security
Michael Cooney writes to tell us Windows Vista may have some serious headaches in store for corporate users with third-party authentication systems like VPNs. From the article: "ISVs say rewriting their code for the new architecture will produce headaches that will extend to their customers that have deployed strong authentication such as biometrics or tokens, enterprise single sign-on and a number of other systems integrated with the Windows authentication architecture."
As expected the summary on /. is just trying to be inflammatory. The real gist of the article is as follows: Vista will require some programs to be re-written, espcially ones that interfaced closely with the old operating system. Thus many authentication systems will need to be updated. It's not really unexpected or unheard of for new APIs to break old programs. So if you want to bitch about how Vista is going to make you rewrite your code go ahead (I know I am not looking forward to it), but don't pretend it is a security problem.
Philosophy.
From what I can tell, TFA is saying that because much of Windows has been rewritten (including logon and authentication), it is going to be a pita to adapt existing software. No frigging kidding. Doesn't this happen with every major update? If so, why is Slashdot even reporting this? It is something that is normal.
Basically, what's this is all about is that the way to alter the login process in Windows, all the way back to NT 3.1, has been a custom "GINA", that replaced part of the Ctrl-Alt-Del login process. Naturally, a lengthy biometric process migth be fine if you do it once a day, but it will both need new software and possibly some thought to work well with a LUA approach, where you need to repeat your credentials more frequently for specific operations. This is basically no different from using sudo or doing admin operations in MacOS X. It's also no different from that you can't use a custom GINA to run a specific app as admin in current Windows versions.
Yeah, cause Linux never has low level compatibility updates between releases. Give me a break. Linux is not a cure all. For example, figuring out whether a program is being compiled on an SMP aware Linux system requires looking in a different directory for a specific include file, depending on whether the kernel is 2.2, 2.4 or 2.6. And of course, for certain distros it will be in a completely different location (and if you give the wrong include directory, there is an identically named file in /usr/include which will be snapped up and used, even though it gives no SMP info, so it's hard to tell you failed). Other aspects of the Linux API change in subtle but annoying ways that will break older code that relied on specific behaviors.
Of course, most programs don't need to know whether it is being compiled on an SMP enabled Linux system. Similarly, most people don't need to know much about the low level Windows API. But when programs are written that rely on it, major updates tend to cause breaks. Don't blame Microsoft for that. Be thankful they are trying to make the API more robust. Hell of a lot better than releasing "Windows XP: Vista Edition with nifty keen graphics" and no actual under the hood improvements.
Vista is also making life very hard for invasive spyware makers like Blizzard (Warden) and NCSoft (GameGuard)...
About damn time.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Also, applications such as games and productivity software which were intended to be run under an Administrator account under Windows XP and earlier operating systems might need to be updated as well in order to work under Windows Vista without presenting an annoying number of dialogs.
Regards,
Aryeh Goretsky
Dexter is a good dog.
TWO years!
And we have had an API for more than one year - to create CredMan plugins.
And the architecture is "better" - more PAM-like.
Now you won't break SecureID with a service pack.
And this is a problem, how again?
"Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
The way "Windows authentication architecture" is extended in XP is very limiting - essentially you write DLL (so called GINA) that replaces part of XP log-in system and this DLL is responsible for retrieval of users credentials for Windows. However it was possible to have only single GINA installed at the same time, so if you wanted to have two security products installed - you were in trouble.
Now Vista will support new architecture for security providers with possibility of multiple providers registered at the same time. A definite improvement for users.
In fact the new architecture is not THAT different from the previous one, so the entire article is moot. Then again, it's SlashDot...
Slashdot - free anti-Microsoft propaganda 24/7
Multiple GINA programs is fairly straightforward.
A single registry value holds what GINA to execute. If the registry value is blank, it executes MSGINA (the Microsoft default).
If you replace the GINA with a 3rd-party program (VPN, Wireless, Encryption, et cetera), then the 3rd-party is responsible for either (a) completely handling the logon, or (b) passing control to MSGINA when it is finished executing.
As a rule, this happens by your 3rd-party GINA keeping a value of its own (in the registry or INI) of what the previous GINA was. That way, if you install a new GINA, when it finishes executing, it calls whatever GINA *used* to be in the default registry location.
First you have MSGINA.
You install ENCRYPT-GINA.
ENCRYPT-GINA executes and calls MSGINA.
Then you install VPN-GINA.
VPN-GINA sees ENCRYPT-GINA as the GINA to execute when complete.
VPN-GINA executes and calls ENCRYPT-GINA
ENCRYPT-GINA keps its own value for what to call next and calls MSGINA.
Add all the GINAs you want.
It's true that *some* GINAs don't play nicely, or won't always execute if a certain GINA has executed before it (or comes after it) - but for the most part it works.
The only REAL problem is when a GINA is stupid enough to place itself incorrectly in the chain -- which can leave a machine executing GINAs in a loop...and Windows is smart enough to restore MSGINA when that happens anyway.
Are you for real?
This is true of user level applications, but certainly not for system level ones. The stuff in Unix is hideously incompatible across incarnations - try parsing
RSA writes driver level code (to keep their proprietary algorithms sekrut) and hooks it to the Windows GUI logon process - that's something that changes between desktop managers on Unix, let alone versions or even incarnations! There may be pseudo-stable APIs there but there's an awful lot of redundancy and it's not exactly a clean landscape (xdm, kdm, gdm, whateverdm etc.)
Now, I'm not remotely suggesting Windows is any better than Unix in this regard, but the only thing it really does have going for it is there's a lot fewer "versions" out there. Like Unix, the core APIs are very stable. It's the fringe and special purpose stuff you have to worry about.
Note also that the same thing happens to Unix from time to time: shadow passwords broke a bunch of stuff, MD5 hashes broke more stuff, pam broke a whole different set of stuff, etc.
Fear: When you see B8 00 4C CD 21 and know what it means
It's not "a good thing" when they change how database connection pooling works.
It used to be recommended practice to stick the db connection in the session object at session.start.
Option Pack 4 changed this behaviour. But it didn't show up until the websites you had already deployed started to get "un-reproducable" errors. The unpooled connections hung around for 30 mins after the last request for that session. Once the site got enough traffic it started killing the application. Could be 6 months, could be a year. Took a while to work that one out, much to the annoyance of my customers, and at my expense "you wrote it, it must be a bug in your code, bug fixes are covered in our agreement". Getting off the MSDN treadmill was glorious.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
If I'd meant Service Pack 4 I would have said it
e commended/NT4OptPk/
http://www.microsoft.com/ntserver/nts/downloads/r
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Less Secure we Complain More Secure we Complain?
Can we just pick a side..
Do we hate Vista because it will be more secure and that is causing Third party applicaiton problems?
Or do we hate Vista because it is not secure enough?
Or do we hate Vista becuase it is more secure but prompts for passwords when doing Root level activities and that will confuse people?
We have to pick a story, we can't be on the opposite side of the fence as each story is released.
Maybe we should just hate Vista just to hate Vista but at least stop contradicting ourselves?
because much of Windows has been rewritten, it is going to be a pita to adapt existing software. No frigging kidding. Doesn't this happen with every major update?
No, it doesn't. Microsoft's track-record for backwards compatibility is among the best in the industry. Sorry, but while their software has many flaws, there are some things they do very well, and not breaking things in upgrades is one of them.
Compare the upgrade from Windows 98 to Windows XP with the comparable upgrade from OS 9 to OS X. You can run practically any bit of Windows 98 software in Windows XP. You can't run any OS 9 software in OS X without buying a separate copy of OS 9 and using emulation, and people on Mactels can't run any OS 9 software in OS X period.
I find it amusing that nobody ever complains about this, but if they find one single piece of Windows 98 software that doesn't work properly in XP, it's all OMG MICROSOFT IS TEH SUXOR!!!!!11. Can you say "double standards"?
Never mind running Win98 software under XP. If you get hold of a copy of Windows 1.0 you can run the applications that came with that under Windows XP. The only quirk is that the app windows open at the smallest possible window size, because Windows 1.0 didn't support overlapping windows and so the apps didn't actually choose a size for themselves.
Microsoft's devotion to backwards-compatibility is astounding. It's just a shame that their architecture has to suffer because of it.