h a l f b a k e r yCaution!
Contents may be not!
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
While we all know that when we press the backspace key, the last-typed keystroke is erased from the screen, not everyone realizes that the backspace key generates a code-number that does not have to do more than ONLY that visual effect. There is a "buffer" in the computer memory that records the keystroke
codes, and its contents normally are backspaced also, so that when the Enter/Return key is pressed, the contents of the buffer can be sent to the next stage of processing (comparing with a stored password, for example).
I propose that, ONLY for password-entry software, while the visual display continues to erase a previous keystroke when the backspace key is pressed, the buffer would not have the previous keystroke erased--indeed, the keycode for the backspace would go into the buffer, also! For example, suppose I want to create a new password, and I decide to type "a1b2c3", and that I make a mistake and actually start to type "a1v". Those three character-codes are now in the invisible memory buffer. If I now press the backspace key to erase the "v", the computer will obligingly do that on the display, but the "v" will not be erased from the buffer, and instead a new keycode for the backspace will be added to the buffer. I now finish typing "b2c3" and press the Enter/Return key. While it LOOKS like my password is only 6 characters long, on the screen, behind-the-scenes, there are actually 8 characters in the memory buffer, being used as the password.
Obviously this means that if I want to verify the password, and actually use it later, then I have to type exactly the same 8 keystrokes as before. But somebody trying to crack my password is going to have a problem! If the cracker doesn't know the backspace is an allowed character, the password will never be cracked. And, even when the trick is known, just by increasing the total number of allowed keycodes by 1, as password characters, that also increases the difficulty of cracking the password by brute force.
Now, what if I need to do an ACTUAL backspace, even inside the hidden memory buffer, because of an actual wrong keystroke? Simple: just use an alternate keystroke combination, such as Control-Backspace or Shift-Backspace, for example. The software that accepts the ordinary backspace as a password keystroke can easily be adjusted to test for the extra associated key, so that the ordinary kind of backspacing functionality can be accomplished.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
UNIX used to let you do this. Trick was to set the terminal's "backspace" function to another keycode. |
|
| |
(or that's what the Internet says; I remember having the screen cursor perform a backspace, but the backspace keycode ended up as part of the password) |
|
| |
Really? The huge majority of average computer users know UNIX? |
|
| |
temporal anomaly on the anno editing. |
|
| |
But, time was when UNIX was the closest thing to personal computing. |
|
| |
OK, thanks for the info, [FT], and what did those UNIX users do when they needed an actual backspacing inside the memory buffer? Enter an invalid password and start over? |
|
| |
sorry, all I remember is finding out the hard way by entering a BKSP to edit, and ending up with an invalid password because it had the BKSP in it, then giggling and changing my password to include SPACE BKSP so it would print out or display without an overstrike. |
|
| |
This was (most likely) the 70's on a VT terminal hanging off a PDP8 (university); I have no clue if a modern UNIX or Linux on a PC allows it. |
|
| |
Interesting. But, if someone can watch the screen, they
would probably watch your fingers instead, in which case
they'd see you type the backspace. And, if someone is
just trying to hack your password, then "backspace" is just
another character to throw into the mix, along with the
70-odd others, so it won't make the password significantly
harder to crack. |
|
| |
So, overall, I don't think it would add significantly to
security, but would add a small amount of hassle. |
|
| |
This is baked. I think you must be younger than i am. I was surprised when, quite recently, i realised you could delete characters in your password. |
|
| |
Good idea, but that's a vast amount of text for such
a simple idea. Who do you think's going to read all
that? |
|
| |
[Vernon] it would help if we knew the circumstances in which
someone might try to hack your password - are they watching
the screen, watching your fingers, or just working cold? |
|
| |
Very Baked, for the last 40 of your Earth years. |
|
| |
[MaxwellBuchanan] I was talking about "cold" cracking, and the difficulty of cracking a password is related to (number of characters in password) raised to the power of (number of allowed different characters). So, (correcting my math error, as pointed out below) for an 8-character password and 75 allowed characters, the maximum number of possible combinations is 75^8, and if one extra character is allowed (like the backspace), then the task of cracking becomes slightly tougher (76^8 possible combinations). For a longer password (say 12 characters) the cracking problem becomes tougher by a lesser magnitude: 75^12 before and 76^12 after allowing an extra character. (Added after correction: Yes, I agree that a longer password is always vastly tougher to crack than a shorter password.) |
|
| |
[Rest of you], I'm still waiting for what UNIX did/does to let you actually-erase a mistake when typing a password sequence (what kind of backspace does NOT go into the character buffer?). If you can't answer that, or if there is no answer besides "enter the mistake and re-try", then that part of this Idea about Control-Backspace or Shift-Backspace is original, and is the key part that makes the rest of it practical for everyone. AND, not actually much extra hassle, since normally when typing a password these days all you see on the screen is a sequence of asterisks, so you already have to type with extra care. This circumstance means that if you know the backspace is an allowed password character, and you know that something like Control-Backspace lets you erase a mistake, being in "extra care mode" should mean you will have that distinction in mind, when typing your password. |
|
| |
[V] sure, you could assign another keycode to perform the BKSP function. Might be easier to simply use that code and leave the backspace key where it is though. |
|
| |
The advantages that you're looking for are:
|
|
| |
a) (cracker is sitting at your desk trying stuff out) a cracker doesn't know that the bksp keycode is an allowable character and doesn't use it. |
|
| |
Yeah, that's pretty straightforward. Of course you'd have to change the function that accepts passwords, and possibly the function that encrypts passwords for storage on disk (in case that one normally doesn't accept the bksp keycode). |
|
| |
b) (cracker has your .pwd file and is trying to decipher it) when your password gets displayed on the evildoer's screen, it will be a couple characters short because *their* screen will be displaying it "normally". |
|
| |
That works too. As previously mentioned by [EveryoneElse] baked, Unix (possibly others) 40 years ago. Feel free to reread my annos for what I remember playing around with it. Note that reassigning keycodes was a function of the terminal (hardware), not the OS. |
|
| |
In both cases, it's a one-off though. [ ] |
|
| |
ummm, might want to think about your combinations/permutations math there or MB will start asssigning remedial homework. |
|
| |
// if one extra character is allowed (like the backspace),
then the task of cracking becomes 8 times as difficult// |
|
| |
So, there are two advantages - the extra length of the
password, and the fact that each character could now be a
backspace (ie,76 rather than 75 characters). Going from an
8 character password to a 9 character password increases
the complexity from 75^8 to 75^9, or a 75-fold
improvement. Going from 75 to 76 characters for an 8-
character password increases the complexity from 75^8 to
76^8, or an improvement of only 1.1-fold (ie, about 10%). |
|
| |
The fact that the password will appear on-screen as one
character less than it actually is will be an advantage, but
only until this becomes widely used, whereupon hacking
software will presumably allow for this possibility. |
|
| |
I dunno. I can see that this gives a marginal advantage,
but I don't think it's much of an advantage over just using a
couple of extra characters in the password, and I don't see
that it would overcome any inherent problems with
passwording. |
|
| |
//I'm still waiting for what UNIX did/does to let you actually-erase a mistake when typing a password sequence// |
|
| |
Submit the error and start again. |
|
| |
//might want to think about your
combinations/permutations math there or MB will start
asssigning remedial homework// |
|
| |
OK, class. First, let me emphasize that one math is never
enough. You need mathS if you're going to do anything
useful. |
|
| |
Now, did everyone get this week's test paper? |
|
| |
1) Everything [FlyingToaster] said. |
|
| |
2) There would be compatibility woes. A backspace can be sent as ASCII #8 (not to be confused with the character '8'), or as the string "^H", and maybe other ways, depending on the context. |
|
| |
3) (Kind of related). On the Commodore 64, you can use the INST/DEL key to open space(s) in a program. Any keystrokes, including delete, will then be stored in the spaces as literal characters, rather than acting in the usual way. It was intended, I think, to allow control characters to be included in strings, but was also a great way to make obfuscated code: when the program is listed, these embedded control characters come to life, for example, deleting part of the code, so it is impossible to determine the behaviour of the program from its appearance. (I hope I got the details right; it's been a while). |
|
| |
//You need mathS// tomato tomato... and if you type n characters and one of them is a working BKSP, how many characters will appear on the screen ? |
|
| |
If you mean the C=64 trick, n when entering (the backspace appears as a colour-reversed character), then n-2 when you LIST the program (the backspace and the character it deletes are invisible; actually, the character appears, then disappear a fraction of a second later, usually too fast to see unless you are lucky and watching very closely). |
|
| |
If you mean [Vernon]'s idea, I don't know. |
|
| |
What i possibly falsely recall, and this was on VMS, not Unix, was that each keystroke combination produced no response from the monitor until i pressed Return. There was no way to correct errors and something like three successive incorrect password entries locked you out. This was on a VT220 terminal used to access a VAX 11/something. |
|
| |
That sounds right, [nineteenthly]. If you type 'h' 'e' 'l' 't' <BKSP> 'l' 'o', then what the remote VAX machine receives is not "hello", but "helt^[[8lo", or something similar. |
|
| |
That's a good example of why this is a bad idea. The above behaviour is a function of using a particular type of terminal in a particular way, and is unlikely to be repeatable everywhere. Whether the byte(s) representing the backspace are seen by the code that receives the password, and in what form, is likely to depend on the platform and the context. |
|
| |
Yes, i can see that it's unpredictable. If you have what's effectively a typewriter which can also send signals to a computer, it's going to echo stuff whether or not you turn it off. There might be a way round that though. If you typed solely control characters, they wouldn't appear on the output as printable, but the choice would have to be very careful and probably wouldn't give you enough permutations for a secure password. |
|
| |
This UNIX behaviour is what's behind all those
crap^H^H^H^Hhilarious unix backspace jokes. |
|
| |
Thanks, [zen], I wondered what those were. |
|
| |
I vaguely recall reading an article some time back where a radiation-therapy machine's operator typed in a command code, made an error, backspaced, corrected and then hit enter. The machine took the backspace as part of the comand code and did a very bad thing. |
|
| |
The radiation-therapy patient spent the next few days as the only living person to have seen Cherenkov radiation in air. |
|
| |
"See Cherenkov And Die". Oh dear. |
|
| |
I have a mixer tape from the early 'eighties with a handwritten correction using ^H's. |
|
| |
By coincidence, I was just reading about the supercriticality accidents in the 1940s. It seems that the blue glow seen in air is not Cherenkov radiation, but blue spectral light from ionised nitrogen and oxygen. Their similar appearance is another coincidence. |
|
| |