Very early in the history of interactive logon with passwords, the big brains noticed that if someone was looking over your shoulder, they might see what you were typing. So they decided that whenever any system, anywhere, asks for a password, it has to be replaced by blobs or asterisks.
We've all become so used to this, that we don't realise how inappropriate it is for 99% of our daily interactions with computers. The vast majority of us will never encounter anyone trying to steal our password by looking over our shoulder, but I'm guessing that almost everybody reading this has been locked out of a system, site, or application to which they had legitimate access by a problem caused by not being able to see what you're typing.
There are many reasons why people type the wrong password. They forget which site they're on, they forget that this system forced them to change their password last month, maybe Caps Lock is on, whatever. (If you're typing the right username but the wrong password into a site, you'd better hope that the site managers don't capture your wrong attempts and then try them on other sites which they might learn that you're signed up for...)
It's also possible that your keyboard layout may not be what the operating system thinks it is. All keyboards are electrically identical, so the only way Windows (etc) has to know what the top-left letter key means, is the keyboard settings which you gave it. If someone replaces their QWERTY keyboard with an AZERTY one, without informing the system via some obscure part of the Control Panel, the top-left letter key might look like an A, but the system will see a Q. And the person typing will still see the same blob or asterisk. (In our environment, we use 15 different keyboard layouts, and people tend to move around and take their keyboard with them. And even if they know how to set up the layout for their current Windows session, they usually don't know that they should also change the default layout so that the new keyboard works correctly at logon time as well.)
This "security feature" must cost millions of dollars in helpdesk calls every year. Eevryone who has ever worked on a support phone line has had people call who are "convinced" that they are typing the right password. Sometimes you can get them to type the password in another box and then paste it across, but that's not always possible, and explaining it to a confused user is often a nightmare in itself ("Don't click OK when the password is in the username box!").
It doesn't even make you very much more secure. Someone who really wants to steal your password while being in the same room can observe your keyboard while you type, perhaps keeping up some conversation to distract you, and after a couple of times they'll have a pretty clear idea of your password, especially since so many people choose insecure ones (hmm, did anyone think that maybe some people do that precisely because it's easier to type "rosepetal" than "h4%tfr3q" when you can't see what you've typed?). Now that we all have LCD screens, it's getting harder to sell us the fantasy that someone is parked outside our offices in a van examining the electromagnetic field from our monitor. And of course, the password-stealing spyware inside your PC gets a full view of every keystroke, unobscured by blobs. It's more than slightly ironic that the bad guys can see your password more clearly than you can.
So imagine my delight when I first saw this feature in an admirable free ZIP/RAR program called 7-Zip:
Yesss! Provided of course that there are no spies in the room, you can check the box when opening a password-protected RAR or ZIP file, so that you can see what you're typing in the password box!
Question: why isn't this feature available on every non-military password dialog box in the world?
10 September 2008
04 September 2008
Not ready for (corporate) prime time
Since Google launched the Beta version of their Chrome browser - it's about 72 hours ago but it feels like a lot longer - we've been getting people asking why we've blocked its download to our corporate network.
The short answer is "because it's not suitable". Sure, it looks great, has better security, Javascript runs fast, etc etc. But it seems like no thought has gone into how one might go about deploying it in a business setting.
First, the only way to get it is by interacting with Google's download site. You get a small installer executable, which then goes back to Google and downloads the rest. During this time, you sit and watch. Is it installing the same code as yesterday? How can you tell? Until we can see a single .MSI file, with the usual command-line parameters allowing for totally silent installation, we can't use this.
Secondly, have you taken a look at where the installer leaves all the files which make up the browser? Well, most of them are in the profile of the user who downloaded it. On an out-of-the-box version of XP this means that your Web browser is in C:\Documents and Settings\username\Local Settings\etc etc etc. This is a disaster in many corporate environments which use roaming profiles, because they typically have fairly strict retention policies about how long old profile copies are allowed to remain on PCs. Although it could have been worse (Chrome could have installed into some other directory at the top of the profile rather than "Local Settings", thus entering the roaming part of the profile and being copied to the server when you log off), this means that in practice you're going to have multiple copies of the browser per PC, but with each individual user losing access to it every time the local profile copy is cleaned.
I wish that this was the first time we'd seen this sort of problem, but it isn't. Although "consumer" products (such as the iPhone and iPod, or any Google application you can name) tend to be the worst offenders in terms of treating your entire PC as if they own it, some business software publishers are not far behind. I hope the person who decided to place Adobe Bridge's file cache in the roaming part of the user profile is reading this.
In mitigation, perhaps I should mention that it took Microsoft about 6 years from the release of Windows NT 4.0 to get their programmers to understand the consequences of roaming profiles. Most MS products now do the right thing, although some are still quick to impose their own view of the world on "User Shell Folders" registry entries if the network is a little slow, with potentially "hilarious" consequences for unsuspecting users who didn't realise that all their new documents are being chucked into an unbacked-up directory on the local hard disk instead of their network drive.
The short answer is "because it's not suitable". Sure, it looks great, has better security, Javascript runs fast, etc etc. But it seems like no thought has gone into how one might go about deploying it in a business setting.
First, the only way to get it is by interacting with Google's download site. You get a small installer executable, which then goes back to Google and downloads the rest. During this time, you sit and watch. Is it installing the same code as yesterday? How can you tell? Until we can see a single .MSI file, with the usual command-line parameters allowing for totally silent installation, we can't use this.
Secondly, have you taken a look at where the installer leaves all the files which make up the browser? Well, most of them are in the profile of the user who downloaded it. On an out-of-the-box version of XP this means that your Web browser is in C:\Documents and Settings\username\Local Settings\etc etc etc. This is a disaster in many corporate environments which use roaming profiles, because they typically have fairly strict retention policies about how long old profile copies are allowed to remain on PCs. Although it could have been worse (Chrome could have installed into some other directory at the top of the profile rather than "Local Settings", thus entering the roaming part of the profile and being copied to the server when you log off), this means that in practice you're going to have multiple copies of the browser per PC, but with each individual user losing access to it every time the local profile copy is cleaned.
I wish that this was the first time we'd seen this sort of problem, but it isn't. Although "consumer" products (such as the iPhone and iPod, or any Google application you can name) tend to be the worst offenders in terms of treating your entire PC as if they own it, some business software publishers are not far behind. I hope the person who decided to place Adobe Bridge's file cache in the roaming part of the user profile is reading this.
In mitigation, perhaps I should mention that it took Microsoft about 6 years from the release of Windows NT 4.0 to get their programmers to understand the consequences of roaming profiles. Most MS products now do the right thing, although some are still quick to impose their own view of the world on "User Shell Folders" registry entries if the network is a little slow, with potentially "hilarious" consequences for unsuspecting users who didn't realise that all their new documents are being chucked into an unbacked-up directory on the local hard disk instead of their network drive.
Subscribe to:
Posts (Atom)