h a l f b a k e r yTastes richer, less filling.
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,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
One of the major annoyances of case sensitive passwords is
accidentally having the capslock key on. This can easily eat up
several entry attemps, locking you out of the system. Sure, some
newer software will warn you that capslock is on, but that doesn't
always help, especially if you haven't
had your morning cofee yet.
My question is, why doesn't software allow inverse passwords? If
AbC123 is your password aBc123 would also be acceptable. This
only cuts the total number of possibilites in half, not a significant
reduction compared to the total number of possibilities.
Edit: Alternate version after realizing not all systems de-capitalize
with both shift and capslock pressed. Have the software ignore or
correct for the capslock while entering passwords, rather than just
telling you it's on. Since the OS is still receiving all keystrokes
from the keyboard, it should be possible to interpret what those
keystrokes would be without capslock on.
[link]
|
| |
My caps-lock only capitalizes, it doesn't invert - capslock, shift-A still comes out as A, not a. Hm. But if it did toggle case as it should, wouldn't the counterpart to AbC123 be aBc!@# ? |
|
| |
[MechE] means holding the shift key while the caps lock is active. This has the effect of reversing the caps lock action. "ABC123" becomes "abc!@#". |
|
| |
(Presumably one would only be pressing the shift key with the expectation of generating the shifted character. The author doesn't appear to be shifting the "123" part of the example in the idea, although that's not made clear.) |
|
| |
Okay, I just realized the having shift de-capitalize
capslock is
not a standard as I had thought. Windows machines do
invert, my Mac does not.
The example in the text were typed on windows at work,
with the capslock on for the second, same keystrokes
otherwise. |
|
| |
That being said, I was trying to enter an alphanumeric
mixed case password, no special characters. On every
keyboard I've ever used capslock does not toggle numbers
to special characters, the shift key is required.
Maybe the correct version of this idea is to have the
software disable capslock instead of accepting both
versions, I'll append that to the main
idea. |
|
| |
This fully baked. Most Domain controllers allow for ignoring case. |
|
| |
This is not ignoring case, that wouldn't care what the case is.
This is still accepts dual case passwords, that is you still have
to hit shift and the letter where needed, but it won't care
what that combination actually produces on the screen. |
|
| |
The fact that some systems do not invert case when you have caps lock on means that you will always have to accept ALL CAPS versions; meaning that the case specificity is entirely lost. |
|
| |
[V^3] Not neccesarily. Even if I have capslock on, the keyboard is still sending signals saying that shift was pressed/held in combinaation with another key. It should be possible for the operating system to neglect the capslock key, and just accept the input as if it was off, regardless of its actual state. |
|
| |
MechE, that is not only OS but more importantly platform dependant. The password checking mechanism used by websites is based upon the final string of text which is sent to a remote server for verification. The remote server has no access or way to access specific shift sequences used during the typing of the password. |
|
| |
Most browsers, however, are now able to tell if something is a password (they ask if you want to save it). If they can do this, then they can ask the OS to pass them the corrected version, rather than the characters. This would handle it locally and pass the remote server the correct information. Definitely some programming involved, but shouldn't be impossible. |
|
| |
MechE, you are right; however that is likely to require rewriting the browser... which is something that web developers would love to do, but cannot yet achieve! |
|
| |
I think if the feature was added to the OS, then the browsers
would be re-written to support it in short order. |
|
| |
You are right [MechE], and in about ten years you will be able to start relying on users have a new OS and a new browser that supports it :) |
|
| |