What's the rationale behind Ctrl-Alt-Del for login
Why is Ctrl+Alt+Del required at login on certain Windows systems (I have not seen it elsewhere, but contradict me if I'm wrong) before the password can be typed in? From a usability point of view, it's a bad idea as it's adding an extra step in getting access.
Does it improve security in any way, and if so, how?
FYI Only In Windows 8 you dont have to type Ctrl + Alt + Del. the login form is there when you start typing.
Related from serverfault: How does CTRL-ALT-DEL to log in make Windows more secure?
IIRC back in the DOS days a program could register a keystroke combination on an interrupt. So TSR applications like Sidekick or other tools could magically pop up when you pressed the right combination. When NT 3.5 arrived it used Ctrl-Alt-Del to get to the logon page. The explanation at the time (no, this was years ago and before the WWW was invencted, I can't provide a link) was that Ctrl-Alt-Del was the only key combination an application could not intercept, it was reserved by DOS. So a malicious application could not intercept it and popup a fake login page.
Here's what Bill Gates himself had to say about it, which sounds like he's trying to describe what @Adnan has answered, to what is perhaps a non-technical audience, before giving up :)
actually on windows 8 you have to click and drag to hide the shade and reveal the login box (which is terrible, my desktop is not a tablet), but that still requires user input on the same physical device.
@james: DOS applications could intercept control-alt-del just as effectively as any other. Indeed, I remember playing the game FlightMare, trying to figure out how to exit back to DOS, and after finally giving up, hitting control-alt-del and *instantly* receiving a DOS prompt. No reboot--just a simple application exit.
@edthethird Try pressing the any key on your keyboard next time you're on the login screen?
This combination is called a Secure attention key. The Windows kernel is "wired" to notify Winlogon and nobody else about this combination. In this way, when you press Ctrl+Alt+Del, you can be sure† that you're typing your password in the real login form and not some other fake process trying to steal your password. For example, an application which looks exactly like the windows login.
In Linux, there's a loosely-defined equivalent which is Ctrl+Alt+Pause. However, it doesn't exactly do the same thing. It kills everything except where you're trying to input your password. So far, there's no actual equivalent that would work when running X.
† This implies a trust in the integrity of the system itself, it's still possible to patch the kernel and override this behaviour for other purposes (malicious or completely legitimate)
As a side note: when you say it's "wired", what that actually means is that Ctrl+Alt+Del is a mapped to a hardware defined interrupt (set in the APIC, a physical chip on your motherboard). The interrupt was, historically, triggered by the BIOS' keyboard handler routine, but these days it's less clear cut. The interrupt is mapped to an ISR which is executed at ring0, which triggers the OS's internal handler for the event. When no ISR for the interrupt is set, it *(usually)* causes an ACPI power-cycle event, also known as a hard reboot.
This is a common, but I think it is wrong. The last 10 years I worked with WIndows devices in medical business. Nearly all showed a differnt behaviour with CTRL+ALT+DEL. The Siemens Healthmen ignored it. Syngo brought an own user login dialog. And so on. (the funny thing with syngo: moste devices have the same administrator password. a user meduser or administrator has an autologin, and afterwards the user can login with ctrl+alt+del...)
@Offler Those customisations were installed as administrator. An application running as an ordinary user still can't intercept the Ctrl+Alt+Del signal.
@r3m0t If you can put something together as addministrator, how secure is it? ;-) Many people are still using XP as admin. The UAC warning seems also to be only something to click away. ATM have just a dialog that looks like the annoying java thing and most people will blindly click update...
While Winlogon itself has customization hooks that can be used to present a different ui, read a smartcard, support a 2-factor keyfob, and so forth, the point remains that those hooks can only be installed by a suitably privileged user. The things @Offler described are all easily done with those hooks, and were certainly installed by an administrator, possibly through a customized system installation kit.
That's what I figured it was for, but I feel like it wouldn't actually work. Just have the fake process wait until a little after ctrl and alt are pressed; what are the odds the user /isn't/ going to also have pressed del, when they're looking at a login screen?
@Erhannis what does the user do when pressing ctrl-alt-delete brings up the task manager?
@immibis Yeah, I suppose that's a fair point. I'm not completely convinced that it's foolproof, but I don't have any further objections atm.
@Polynomial do you have any evidence to support what you're saying? As far as I know, Ctrl+Alt+Delete is a Windows shortcut that gets registered by the logon UI (used to be winlogin I think). As far as interrupts are concerned, we're talking massively about USB-HID, and I doubt any controller has a special interrupt for Alt+Ctrl+Delete, especially they wouldn't process keys but just transfer them to the OS. I'm not aware of it being any different if you'd use PS2.
@user1532080 Easiest thing to do is search for "ctrl+alt+del interrupt bios" for reference. I think the APIC part might be different on different systems, but USB-HID is irrelevant here. The BIOS has a keyboard handler (which can manage USB-HID these days) that has the ability to catch keys before the OS gets them. That's why CTRL+ALT+DEL reboots your machine if you press it during POST.
@Polynomial That search does not give any proper result for me. Yes, BIOS has a keyboard interrupt handler (handling int9). To the best of my knowledge, there's no specific interrupt for that key sequence. Yes, Ctrl+Alt+Del reboots during POST because BIOS keyboard handler does look for it specifically. Keyboard sends "make" and "break" messages when keys are pressed . BIOS keeps track of key currently pressed and identify the sequence. If there was a specific (hardware) INT for that key combination, then it should always have worked, unless a tool specifically decided to hook it.
@Polynomial If there was such an "Ctrl+Alt+Del" interrupt, what device would trigger it? Would it be the keyboard tracking its own state and triggering it? The PS/2 keyboard controller? Do the USB controllers still integrate it? Because I can tell you it's not the keyboard, I write keyboard firmwares.
@Polynomial Oh and by the way, historically, what BIOS handler would do is "JMP FFFF:0" (which is a soft reboot) when Alt+Ctrl+Del was identified. Again, to the best of my knowledge, absolutely no interrupt involved beyond the regular keyboard one. Also I would have to disagree with some things you said about the BIOS catching keys before the OS, any proper 32 bits OS does not run any BIOS code (BIOS is 16 bits, I won't enter into details)... That's pretty much any linux, any Windows from the NT branch.
@user1532080 This is kinda hard to convey properly over comments, due to size limits, but I'll give it a go. To start with, for simplicity, I'm just going to say "BIOS". I know there's a difference between BIOS and EFI, but I'm going with brevity over specificity. In the BIOS, USB keyboards are accessed in legacy USB mode via an emulation layer. This works by providing a translation layer that exposes a USB keyboard as an 8042-compatible interface via IO ports 60h and 64h. Code running on the CPU can then use IN/OUT to talk to this interface and issue 8042 commands.
@user1532080 When a key is pressed the BIOS raises INT 9, which is mapped to IRQ 1. Originally this was done by physically asserting the IR1 line on an Intel 8259 PIC, which asserted the INT line on the CPU. The ISR for IRQ 1 then interrogates the 8259 to find out which interrupt was raised. In more modern systems there are internal APICs and external I/O APICs, which are connected via the system bus or LPC (using SERIRQ). The keyboard is connected via the PCH (also sometimes SuperIO). The PCH then interfaces with the CPU via a proprietary method (e.g. DMI3) to provide access to the devices.
@user1532080 The jump to `FFFF:0000` does NOT cause a soft reboot. This is a misconception, probably derived from this poorly worded document. The reset vector is executed by when the CPU comes out of a reset state, not the other way around. The address `FFFF:0000` is derived from the segment register and IP register values at reboot: on an 8086, `CS` is set to `FFFF` and `IP` is set to `0000`, which is written as `FFFF:0000`. This translates to a physical address of `FFFF0`. This is different on later CPUs.
@user1532080 The modern side of this gets very complicated. Modern keyboard controllers include a legacy KBC interface (accessible over 60h/64h IO ports, or via alternative means such as MMIO or LPC) which can trigger a CPU reset via command FEh (I have validated that WinXP uses this method to reboot). This asserts a reset line (e.g. `KBRST#` on the ENE KB3700) which is usually tied to the `RCIN#` line on the PCH. This then forwards an `INIT#` signal to the CPU via some mechanism (e.g. VLW).
@Polynomial Thank you for these details and the links! Yes, let's not talk about UEFI... I'm still missing one bit of "proof": the dedicated interrupt for Ctrl+Alt+Del? There's also one thing I don't get... if KBRST was tied to RCIN, AND KBRST is pulled up when the keyboard controller gets Ctrl+Alt+Del, that raises 2 questions: How comes OS can override it? How comes in MS-DOS era you could disable Ctrl+Alt+Del (Which from the top of my head was done by hooking int 9)?
@Polynomial Also the JMP FFFF:0 in my case does not come from any website. It comes from about 30 years ago, the code I'd write to cause a then called "cold-reboot" (by opposition then to warm reboot, int 19... at the time on my 286 I found warm-reboot to be faster but unreliable... https://en.wikipedia.org/wiki/Reboot#Warm ). As to where I found that at that time, probably in "PC Intern" by Michael Tischer, or some other system programing book. More modern reference: https://en.wikipedia.org/wiki/Reset_vector
@Polynomial I think I see what you mean... JMP FFFF:0 would certainly reboot my 286, hence "soft reboot"... Blank screen, then POST and boot... (unlike int 19 that would skip POST). From the top of my head, JMP FFFF:0 was also found when dis-assembling the default int 9 handler. I might be wrong, again, that's nearly 30 years ago. I'd love to if you'd have some link describing that interrupt that would have been triggered by Ctrl+Alt+Del :)
@user1532080 Yes, if you jump to `FFFF:0` by yourself on a system from that era, it'll load the first block of data from the boot sector and execute it, which in those days was a (not recommended) way for an application to restart the system, back in the days when the OS only ran one program at a time.
@user1532080 Now that I've done more digging, you're correct that I explained it poorly in my original comment. You can refer to the IBM PC ATv2 keyboard code for reference regarding the BIOS having its own handler for rebooting. You can see that the IRQ 9 handler tracks Ctrl+Alt+Del and jumps to a start label (soft reboot) when that occurs. What the OS would do is modify the IVT to point elsewhere, in order to override that behaviour.
@user1532080 The critical part is that on the 386 and later you get protected mode, and in that mode you couldn't write to IVRs. This meant that the OS could install an INT 9 or IRQ 1 handler, but protected mode code couldn't overwrite that handler, so if you pressed Ctrl+Alt+Del there was no way for you to hook that as an application and get the OS to handle it, unless you got code running in real mode. The 8042 in the original IBM PC AT had the facility to do the hard reboot, but this appears to be a separate mechanism that was not specific to Ctrl+Alt+Del.