Monday, May 30, 2005

Some computer annoyances.

I've had a few pet peeves about how computers work for many years and I thought I'd air them here. Firstly, login procedures.

Why are password dialogs not more secure? How many times have you had some program pop up and ask you for a password while you are in the middle of typing, you've not noticed and pressed some keys and Enter in the course of your work? Or how many times have you been in the middle of writing a password when something else pops up or shifts the cursor focus so you end up typing the password somewhere completely different? (Hotmail's login dialog comes to mind because sometimes it would change focus if you typed in your password before the scripts on the page had finished loading, meaning you typed your password on the login name box for all to read).

In the same way that Windows has the "press Ctrl-Alt-Del" to log on, in order to ensure that your password can only go to the one program not affected by Ctrl-Alt-Del, i.e. the login dialog, shouldn't we have some facility within the OS itself to prevent other passwords being scattered willy-nilly when they are entered?

Maybe a system-default password screen. If the user needs to enter a password for any purpose, they have to click on the password box itself, which is just a large rectangular link. When that is clicked, the screen is blanked, the keyboard is locked to every program but the login system (so preventing software key-loggers) and a password dialog appears asking you to "Type in the password for Opera 8.01 to access the website" or "Type in the password for Control Panel to access your network configuration" or "Type in the password for SSH to login as the user root on remote system".

This screen would also be secured by the operating system somehow, to ensure fake screens could not be generated (even though they would require user-interaction to do so). This could be by some sort of visual cue which cannot be modified or overlaid by any program by the system itself (in a similar vein to the secure icon in web browser which SHOULD NOT be able to have a website overlay it's image) or by using the clever tricks that people are suggesting web browsers should use such as a customised screen which nobody but the system has access to... therefore the program would have to know what the user's customised login screen looked like. Any deviation from their picture of The Simpsons beating up a computer and the user would know that it was a fake login box.

[Incidentally, I once used a technique many years ago, before the web was popular, to obtain an admin login at my old school. Using Visual Basic and the PrintScreen button, I was able to replicate the look and functionality of the RM software login screen that the school was using at the time, even down to the help dialogs and pixel-perfect positioning, and got my sixth-form computer science teacher to log into the machine. It was set up so that it failed consistently with any login but wrote the username and password to a file.

The computers at the time had a problem that they would fail to log in with the exact same message if they had been disconnected from the network since they booted up, no matter if you reconnected them later on. The way to fix it was to reboot from the login screen. My program simulated this functionality and was run from within any non-privileged user account. Once the admin had typed their username and password, they got the error they thought meant the computer had to be rebooted, they would reboot, come to a GENUINE login screen and log in successfully. However, the username and password they had tried would be logged to a plaintext file on the user account I had run the program on.

Honestly, I let the person in question log in, then immediately told him what I'd done. Stupidly, he had challenged everyone in the sixth form to try to get admin access, seeing it as a learning experience, and had foiled several previous attempts to steal his username and password. The only other success was when someone read his password over his shoulder and then created dozens of admin accounts using it, using their own name. They were quickly spotted and caught. Mine wasn't and would never have been as multiple logins from the same username were allowed and I would have had time enough to circumvent the measures in place which showed up admin users on the system (an easily subvertible two-line "cron job" that showed all admin users on a spare monitor in the server room)]

Ideally, there would be a fourth LED on your keyboard, indicating "secure" status which can ONLY be toggled by the operating system itself, not application software or device drivers. This would light only when the REAL login screen was up and people would be trained to realise that if the light's not on, people can read their password.

This should also stop the problem of accidentally writing your password at the end of the username box. Either a special button or key combination (even as simple as tabbing to the password field in question and pressing enter) would take you to the secure password screen. The light on the keyboard would be enough to show non-touch-typists that they are in the password box, the blanked screen for the login procedure enough to show touch-typists that they are in the right place.

I do consider password showing on the screen to be quite a weak link, though not completely unstoppable. For a busy user, though, especially around kids or teenagers, this would be a great way to stop unintentional password theft.

No comments: