Slashdot Mirror
Password Autocorrect Without Compromising Security (threatpost.com)
msm1267 quotes a report from Threatpost: Intuitively, auto-correcting passwords would seem to be a terrible idea, and the worst security-for-convenience tradeoff in technology history. But a team of academics from Cornell University, MIT and a Dropbox security engineer say that the degradation of security from the introduction of such an authentication mechanism is negligible. The team -- Rahul Chatterjee, Ari Juels and Thomas Ristenpart of Cornell University, Anish Athalye of MIT, and Devdatta Akhawe of Dropbox -- presented their findings in a paper called "pASSWORD tYPOS and How to Correct Them Securely" at the recent IEEE Symposium on Security and Privacy. The paper describes a framework for what the team calls typo-tolerant passwords that significantly enhances usability without compromising security. The paper focuses on three common types of password errors that users make while typing: engaging caps lock; inadvertently capitalizing the first letter of a password; or adding or omitting characters to the beginning or end of a password. By instituting an autocorrect scheme, the researchers said in their paper that they could reduce common mistakes and user frustrations with logins. Recently, an anonymous user asked Slashdot how one creates a highly secure password after a study from Carnegie Mellon issued a warning about common user misconceptions. You can engage in the conversation and/or read the witty responses here.
I just let pwgen generate my passwords. I basically use two: low sec (e.g. my login passwords) are eight characters, hi sec (hd and backup media encryption, ssh key passphrase, bank token) are 16 characters.
I just generate one, i.e. I don't pick a "nice" one, so I'm out of the equation.
I memorize them. I never use the same password twice.
Seldom used passwords are in an encrypted file. Passwords I use frequently are just in my head. I don't even trust firefox with them (heck: I trust my browser with as little as possible).
At first, memorizing a 16-length pwgen seemed hard. These days it just takes me about two days. In this time, I carry it on a little paper slip in my pocket (I'm especially vulnerable at these times, like a lobster changing its skin: I love this image :-)
So you are willing to reduce the search space by factor of 2^N where N is the length of the password?
Having a maths background, the ability to have x and X refer to different things is natural, useful, and the inability can be annoying. I haven't read the article, but essentially what I imagine is that, given a mismatch when checking exactly (that is, hash and compare to stored hash), it is then easy for the server to calculate say 1000 likely variants assuming the presence of a typographical error, and try those. The insecurity is mitigated by making your minimum length 2-3 characters more.
John_Chalisque
It seems that all major research starts on XKCD...
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
If the alternatives are writing the password down or using short passwords, sure.
Yes, because that makes passwords more user-friendly, which ultimately makes them MORE secure (no need for the user to write them down in a post-it, and all that).
If you remove capitalization as a factor, people would need to choose longer words and more symbols, so it even may prompt a net security gain overall.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
The filename is a variable, Filename is a class, and FILENAME is a constant. Or whatever your code convention says. As long as the codebase is consistent, it makes the code a lot easier to follow.
That certainly is better than having to guess what it should be, or using a variation of pattern like filename_var, filename_class, filename_const.
You also could similarly argue that long names are bad. Just use f for file name, etc. If you think that is bad, think about the reason (loss of information) and why some others prefer having case-sensitive names.
In my country, along with caps lock, many people will switch between local and English keyboard layout so instead of 123 they will type ÄÅÄ. Another one back home is qwertz versus qwerty. I wish someone implemented this a long time ago along with the 'caps lock ignore' feature. By the way, it is quite unlike case insensitivity because you just accept two versions - Password and pASSWORD - pAsswOrd would not be accepted. That actually till keeps the security pretty high I would say, with a decrease of the search space to one half of the original for each 'forgot to switch' factor.
> would need to choose longer passwords
See the optional part in that sentence?
Thats why its not gonna happen.
Also the most insecure passwords are already lowercase only.
This would just make "password" as secure as "Password" - while atm the second is much more secure than the first one.
I suppose it's OK if, on login, if the entered password does not match, they try with simpler versions but NOT more complex ones.
For example, if the password is "password", then "Password" and "password]" will be accepted as correct.
However, if the stored password is "passWord]", then "passWord" will not be accepted and neither will "password]"
So basically, the system should try removing capitalization and removing extraneous characters, but not adding them. This would indeed increase user-friendliness without affecting security much. Hackers tend to try the simpler versions first anyway.
Another thing I wish people would implement everywhere, is not counting duplicate login attempts with the same erroneous password or pin towards your allowed number of login attempts. If someone types the wrong pin (not a typo, but just a mistake), he will usually try it a second time before realising it was a different one. Then, on the third attempt, a single typo can block his card. Counting multiple entries of the same code as a single miss will have absolutely no negative effect on security but will make a big difference in user-friendliness.
I'm a C# coder
That explains a lot.
If this ever starts to take hold it might really screw up those people who use the same password in multiple places. If I use a password frequently in a place where autocorrect is implemented, I might re-memorize the password incorrectly both in mind and in muscle memory. Then, when I enter the 'same' password in the place where I use it less frequently, and where autocorrect isn't implemented... OOPS!
'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
That is nothing but an assumption on your part.
I think they are going a bit further than that; based on the examples in the summary, then for the actual password of "p@ssword" the system would also accept "P@SSWORD", "P@ssword", "p@sswor" and "p@ssword1". That's all well and good if you have access to the original password and can apply the auto-correct algorithm to see if what was entered is good enough, but how is that supposed to work if you are taking password security seriously and using salted and hashed passwords? The article isn't totally clear on this, but it seems that in the event of an authentication failure they'll just retry with each auto-corrected variation in sequence until they either get a match or run out of permitted options. Unless both ends of the transaction are making allowances for this (allowing more than three retries for instance), that might actually cause more problems than it solves through locked out accounts, etc. and might also open up new means of attacking an account.
As always, it sounds like the devil is lurking in the details...
UNIX? They're not even circumcised! Savages!
So instead of just making sure the user learns from the bad input, we'll just let them go ahead.. Sorry, but to me it's just stupid, yes it might be annoying at times, but if it happens a lot, then you might want to consider fixing the problem yourself and not let a system help you with your own faults during entering the password.. If the capslock is on, just tell the user the capslock is on, not help them circumvent it..
But to the same human, jack and Jack is not the same.
"I helped my uncle jack off a horse"
"I helped my uncle Jack off a horse"
Instead of weakening passwords by assuming that some combinations are errors, let's fix the main cause of password typos, the masked entry field.
Think back on the last hundred times you logged into something with a password. Other than at the ATM, in how many of these cases could someone have been looking over your shoulder? The only times when you need a masked field is when you're standing at a dedicated device with people lined up behind you. On computers, a 'mask this password' checkbox option will cover that occasional instance when you're in a public environment.
The whole concept of locking an account for too many login attempts is broken. It's nothing more than a denial of service vulnerability.
(Locking out the IP address is another matter in most cases).
Correction, 26^N
That's bullshit, because you already CAN use lowercase passwords, but you do not need to.
With salted and hashed passwords it would need to be the client generating the auto-corrected versions - the server should never, ever, have any idea what the actual password was and just retain a copy of the hash to mitigate against brute forcing, but otherwise yes, the lost security would be offset by adding a few more characters. What I'm currently trying to figure out is what additional impact (if any) combining this with a scenario involving dictionary attack and rainbow tables might have on the net security of the system. My initial gut feeling was that you would need to add more than 1,000 extra combinations to the password through additional characters to offset the loss of allowing 1,000 variants - and possibly a lot more - but I'm coming up short on actually quantifying it; ultimately you *still* need an exact match, so all the proposed system is doing is a small scale version of a dictionary attack, so maybe there's no change there at all.
One way it absolutely weakens your overall security though is account lockouts through retries; you are going to need to allow a lot more retries for this to work, which is going to allow kiddies trying lists of popular passwords a *lot* more attempts before they trigger an account lockout. Tools like Fail2Ban are incredibly effective when you only allow three attempts before blacklisting the IP (bonus points if you do so across your entire estate), but if you need to set that to a few thousand to allow for auto-corrected variations then what's the point?
UNIX? They're not even circumcised! Savages!
Having auto-correct eliminates deliberately misspelled words, and thereby reduces attacks to a dictionary attack (the simplest kind).
I didn't think so, so I ran the numbers. Disregarding dictionary attacks, you have to brute-force 26^8=2^10^12 tries to nail "password", and 52^8=1x10^14 tries to brute-force "passworD", but 26^10=1x10^14 for "passwordab", which adds only 2 letters.
You're absolutely right. Doubling the character set from lower case to both cases only gives you a puny increase in entropy for passwords of non-trivial length. Clearly adding digits and punctuation characters doesn't help much either. A time-honored myth disposed of so readily.
But I still think a truly random word sequence is better[*]. If the following sequence of words is randomly chosen from a 100,000-word dictionary, it has an entropy of 100000^4=1x10^20.
unpleasantly limiter's citified chronicles
Note: that's only a sequence of 4 to memorize, rather than 8-10.
[*] CERTAINLY not a phrase or sentence that appears in literature, which is a siren song to choose. Whether an extemporized grammatically-correct and meaningful phrase or sentence is OK, can be argued. It's certainly a lot easier to remember.
Linux distros, pure crap, unless you mean Slackware. Full of cargo-cult programmers who think they're cool because they're not using Windows. Crap is crap no matter what OS they're using, they just get to circle jerk with a bunch of other yuppies who think they're awesome for hating on M$.
Yeah those people are not as sophisticated as those who think they're awesome for hating on M$ AND Linux. Clearly the more O/S you hate, the more awesome you are. That's why I hate Windows, Linux and *BSD. I prefer OpenVMS, which is not perfect but those people are a lot more mature and realistic.
lucm, indeed.
I'm a C# coder
That explains a lot.
Oh I see, it's funny because you imply that being a C# coder is bad! Good one!
lucm, indeed.
If common problems include Caps Lock being on and the first letter being capitalised, sounds like the user frustration is with the input device.
I have a coworker who is Caps Lock challenged, so I configured her computer to have that key behave like Shift. Life has been a lot easier for everyone since then.
lucm, indeed.
TRIGGER WARNING: Anecdotal evidence
One of my favorite passwords was based on the word wizard. I didn't often type z's, let alone x's...I set up a new Linux box and my root account (before all this safe don't-ever-use-root-use-sudo bullshit). Trying to log on to my system the first time, I couldn't get the password right no matter how careful I was.
Finally, I decided to type it quickly and see what "muscle memory" did. wixard.
Ahh! There it was, a simple typo (I had to type it at the prompt to see what the text actually came out to be), but made my "wizard130" intended password a little bit stronger: "wixard130". Not much, but a bit. Me and a buddy used variations on that for years. I still use it on some of my offline Linux boxes because that's one that I'll never forget.
Autocorrect be damned; let the users mess up their own shit and quit automatically fixing stupid.
There are plenty of sites that require at least one uppercase letter in a password. And others that require at least one number. And others that require a non-alphanumeric 'special' character "()(*&^%$#@!". And others that do not ALLOW a non-alphanumeric character. And in some technological backwater there are probably sites that require ONLY uppercase or ONLY lowercase. The result is conflicting requirements that make it much harder for people to create and remember strong, long passwords.
If every site allowed a password like "MyPasswordOnSlashdotIsUnicornDroppings", it would be easy for people to have a mental system in place to create strong, unique passwords for every site. Autocorrect would help usability here, but would still not make a dictionary attack feasible when there are 7 or 8 dictionary words strung together.
Yes I know some people think XKCD is wrong and everybody should be using random passwords and a password manager, but personally I think A) they are full of shit, mainly because cross-device password manager usability sucks (especially when you're unwilling to trust your passwords to a cloud service, as I am), and B) that's just never going to happen anyway - people aren't going to switch to password managers en-masse ever.
I mistype passwords all the time due to manual dexterity issues (You try having a stroke) what they are suggesting sounds like a horrible cludge the only functionality I'd like is to be able to select a few of the characters in my masked password and be able to sneak a peek at just the selection.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
With salted and hashed passwords it would need to be the client generating the auto-corrected versions.
That is not correct.
There is already code on the server that generates a hash from the user input, in order to compare the new hash against the stored version. That's the code that would generate hashes from the auto-corrected variants as well.
I saw an article once talking about how Facebook stores both your hashed+salted password and its case-flipped version. So, leave capslock on and it'll match, for a pretty small loss of protection.
Pretty small? I would think that having two hashes from a reversible permutation of the plaintext can have a very significant impact on how easy it is to break.
No, it's not four or five additional entries - that's just how many examples are given in the summary. The "extra characters" option blows that away since it could be *any* extra character, so unless you start getting clever with keyboard layouts and adjacent keys that could potentially mean almost any character on the keyboard, shifted, unshifted and so on. Technically though you could certainly have the server store all the acceptable hashes, which gets around the breakage of tools like Fail2Ban as you'd have to hit a valid match (including typo variants) within a much smaller number of retries, but that does nothing to fix the issue of a kiddie doing brute force attacks of common passwords as they could send "P@ssword" and still have all the auto-correct variations (whether it's just three/four, or thousands) tried in a single hit.
UNIX? They're not even circumcised! Savages!
There is nothing wrong with an all lower case password of an appropriate length.
The Daddy casts sleep on the Baby. The Baby resists!
Are you positing that the client creates the hash from the user password?
That's not how it works. If the client generated the hash, then the hash would essentially become the password, and all of the benefits of hashing and salting would be lost.
There's a pretty good discussion here about why hashing occurs on the server:
http://security.stackexchange....
Computer: > Password
User: > Rameses
Computer: > Uh, you want to tack on anything there buddy?
User: > 2?
Computer: > Come on in
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
Maybe they can apply this to those terrible security questions. Was my high school mascot the Cardinals or the Red Cardinals? Which one did I type when I was first asked this question, because we used to call ourselves both when I was in school. And did I capitalize it? And did I pluralize it? I got locked out of an important system because of this, and it was a system that didn't need that level of security.
Secession is the right of all sentient beings.
If you don't want case sensitivity then don't create passwords with mixed case. The purpose of course for mixed case is to increase the key strength for any given length of password.
There are plenty of sites that require at least one uppercase letter in a password. And others that require at least one number. And others that require a non-alphanumeric 'special' character "()(*&^%$#@!". And others that do not ALLOW a non-alphanumeric character. And in some technological backwater there are probably sites that require ONLY uppercase or ONLY lowercase. The result is conflicting requirements that make it much harder for people to create and remember strong, long passwords. If every site allowed a password like "MyPasswordOnSlashdotIsUnicornDroppings", it would be easy for people to have a mental system in place to create strong, unique passwords for every site. Autocorrect would help usability here, but would still not make a dictionary attack feasible when there are 7 or 8 dictionary words strung together. Yes I know some people think XKCD is wrong and everybody should be using random passwords and a password manager, but personally I think A) they are full of shit, mainly because cross-device password manager usability sucks (especially when you're unwilling to trust your passwords to a cloud service, as I am), and B) that's just never going to happen anyway - people aren't going to switch to password managers en-masse ever.
No, they wouldn't. You seem to assume users have a set amount of effort they'll spend on a password, correct? That's a false assumption - because, most users will spend as little effort as possible. If FOOTBALL is the same as football, do you think they'll switch to something like "football12468;|"? No, they'll pick... football. But now, it's also Football. And fOotball. And FOOTBALL. Some limited forms of autocorrect don't really weaken security, but if we go to password case insensitivity, you are striking out a significant amount of work, and not only is cracking passwords quicker but it's more likely you'll have collisions (and yes, I know about salts, but many web developers don't).
What we need to do is to educate people on why strong passwords are important - and recommend some simply tricks that really can add security with a trivial amount of overhead, such as maybe adding a single phrase to the end of them all, so they remember it as "password" + extra phrase. Another method is to try to remember a catchy made up sentence, XKCD style, and then add some special symbols at the end like $$$ or <3 or whatever to help defeat dictionary attacks, and you've got a reasonably secure password with little extra effort.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Given that Dropbox has previously considered passwords to be optional, I'm not convinced that Dropbox engineers adds much credibility to this research.
http://techcrunch.com/2011/06/...
And how are they hashing the passwords if they are allowing for typos?
Ummm....having case-insensitive passwords is a Terribly Bad Idea(tm), which you'd realize if you'd thought about for even a moment or two.
So..."MyPaSwoRDsTrinG" should be equivalent to "mypasswordstring"? Really?
What kind of head injury do you have??
Just cruising through this digital world at 33 1/3 rpm...
your password is "Not today and perhaps not in the next 2 or 3 decades."? that's pretty good. not sure I would have posted it on the internet, though.
i could live a little longer in this prison
I spent 15 years developing a log in and security system used by about 80,000 web sites, and have had the opportunity to analyze millions of log in attempts. Based on that experience, heres what I do. People copy-paste user names and passwords and when they do, they get extraneous spaces at the beginning and end. So we trim spaces from the beginning and end (not the middle).
Some people use caps lock when they set their password, but most don't, so we show a big warning message if caps lock is on. Later, gdm (the Linux log in) started doing the same.
20 years ago I was working on a SunOS setup, and we would periodically crack our own users passwords to let them know when they were vulnerable.
I don't recall the specifics, but one user was failing with something like 'Password'. The user was befuddled because they swore they used much longer passwords with a bunch of hardening tacked on the end. They had been dutifully typing the 20 character password they had selected, not knowing the SunOS system at the time would truncate to 8 and check only that.
Anyway, the discussion around 'helpfully' automatically helping user have an easier password reminded me of that. Our systems were 'helpfully' allowing users to mess up things after the first 8.
XML is like violence. If it doesn't solve the problem, use more.
That's all well and good if you have access to the original password and can apply the auto-correct algorithm to see if what was entered is good enough, but how is that supposed to work if you are taking password security seriously and using salted and hashed passwords?
If you don't have access to the password that the user entered, how do you check their password at all?
No, they wouldn't. You seem to assume users have a set amount of effort they'll spend on a password, correct? That's a false assumption - because, most users will spend as little effort as possible.
You seem to assume that users will have a choice in the matter. I would expect that any site implementing a password autocorrect feature would also increase the minimum length to something significantly over 8 characters so as to prevent usage of single words as passwords.
No, they wouldn't. You seem to assume users have a set amount of effort they'll spend on a password, correct? That's a false assumption - because, most users will spend as little effort as possible.
You seem to assume that users will have a choice in the matter. I would expect that any site implementing a password autocorrect feature would also increase the minimum length to something significantly over 8 characters so as to prevent usage of single words as passwords.
Ahhh... but if the only requirement is length, you don't think we'll see "passwordpasswordpassword" become popular?
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
(Locking out the IP address is another matter in most cases).
That still allows a bad actor behind a carrier-grade network address translation (CGNAT) to DoS a hundred legitimate users behind the same CGNAT. And with IPv4 address exhaustion, many mobile ISPs and ISPs in late-developed countries have deployed CGNAT so that the Internet can have more than 4.2 billion users.
You have gained exactly nothing if the Capital first letter is enforced by the password policy.
Those password policies drive me crazy. They make no sense from the average user perspective, only to the CIO that can say "see, we're very annoying with our password policy, so that makes us very secure". And if anyone chooses Password1! as a password, it is their fault !!
From now on, my systems are going to require that all passwords include an emoji character.
Crack that, you rotten blackhatters!
And while we're ranting about capitalization and special characters (%$*&#), why not just give up and realize that everything inside a computer is 1s and 0s? Require all passwords to be a string of at least 110111110111 1s and zeros.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
What, that accepting a correctly-typed password will be more welcoming than rejecting it because of a system mode error? I have empirical evidence for all the times my password has been rejected by typing it with Caps Lock enabled.
Heck, the Windows login screen had to include a warning for Caps Lock due to all the users failing because of it.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
You don't understand the problem. Having a lowercase password won't help you when you happen to type it with Caps Lock enabled.
Not that it prevented you from posting an inflammatory post.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
So? That's not inherently less secure than the shorter PasswordPassword, even if the later is caps-sensitive.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
So you'd create an Auto-Mistake generator based on common typos. The problem is that people make a LOT of different typos. PBKDF2 would be running until next week keeping up with all the variants on a single password.
John
This would almost certainly require storing passwords with reversible encryption instead of a hash; how else can you check for "sufficient" similarity or dissimilarity without knowing the password? What algorithm would you use to determine "this character can be dropped, but that one can't?"
Moderate drunk! It's more fun that way!
So? That's not inherently less secure than the shorter PasswordPassword, even if the later is caps-sensitive.
But it's not an improvement. If anything, it's worse, because it leads to a false sense of security. It's a much better use of effort to convince people why it's important, after which they'll naturally adopt strong passwords, as opposed to trying to force them into something they don't want to do.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Sure, but to brute force my account it would take millions of tries not 3. The limit is off by MANY orders of magnitudes.
You're redefining words like "correctly" to only match certain reduced values. Correct is normally understood to mean correct; not partially correct, or correct-except-for-details.
User enters "password]"
Does the hash for "password]" match? Nope
Does the hash for "password" match? Yes, acces granted.
No need to reverse the hash.
Not that that is not the approach taken in the paper, theirs is quite a bit more complicated.
But that's not how the secure password systems these days work. The ones that are worth their salt (no pun intended) never actually send a password to the remote host. They use the password to create a crypt which the remote server can re-create using what it knows of the password. The only way to actually do this sort of "auto-correction" is to make multiple actual attempts against the auth server. The auth server cannot tell whether these attempts are auto-correct attempts, or someone trying to brute force the password, because it cannot see that "oh that's the right password just with capslock on", all it sees is "0xa1362356322bcba173823cd1763726372323d != 0xf563782893287facde". So you have to decrease the security because the auth server has to be told to allow more bad authentications before it starts tar-pitting or locking the account.
(Still waiting for XKCD to do a ven diagram of "things you should not use as passwords" against "things banks ask you for security questions")
Someone had to do it.
You have a point there.
TFA didn't suggest case-insenstive, but rather "caps lock on" and "first letter unintentionally capitalized". That costs 2 bits of password entropy, not bad.
But really, case insensitive doesn't cost you that many bits of entropy for most passwords.
Socialism: a lie told by totalitarians and believed by fools.
In a business context, leadership is all about leveraging people's strengths, not fixing their flaws. So when I have an opportunity to solve a problem quickly and get the resources focused on value-added tasks, I take it.
lucm, indeed.
I wonder if the NSA can snoop on carrier pidgeon traffic.
lucm, indeed.
If my fingers produce the exact sequence of key presses that constitute my password, how is that sequence not correct?
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
People will never "naturally adopt strong passwords", and pretending that "they will, if only technicians bother them sufficiently" is the main reason why security by passwords is the clusterfuck that it is.
Designing the security system around the behavior of its users is the proper way to do it, rather than forcing users to adopt the behavior requirements of a bad system.
In the meantime, I welcome any attempt to make the life of password users less miserable. The password system is NOT secure as commonly implemented throughout the IT systems of the world, so we might as well make it more forgiving, until we get to replace it by something better.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Ahh - good point. I spend my time worrying about authenticating users using web browsers, so I haven't used any of the zero-knowledge protocols. Maybe some day things like SRP will become commonly available in the web world, but I'm not holding my breath ...
> would also increase the minimum length to something significantly over 8 characters so as to prevent usage of single words as passwords
how long?
Come for a visit to germany and meet the Donaudampfschifffahrtskapitaen.
YOU don't understand. But think you for flaming.
The point is, you should not make passwords case insensitive, but you should not force upper case letters either. Because you would rule out all all-lowercase passwords, thus making the set of possible passwords smaller.
And for caps lock there is an easier solution: show the user an indicator (or fully ignore the capslock). The indicator has some advantage, when the user uses caps lock on purpose.
Designing the security system around the behavior of its users is the proper way to do it, rather than forcing users to adopt the behavior requirements of a bad system.
Too many security people don't understand this. Obvious there are degrees of compromise, but I've seen way too many instances of security necessarily hassling people to the extent that they circumvent it in a manner that's even more unsafe.
http://www.newser.com/story/21...
What's a BOFH to do? With auto correct this could cut down trouble calls a lot. It's a BOFH's highlight of the day to get those calls.
http://bofh.bjash.com/
Showing the indicator is almost useless, as proven by the Windows login dialog; people typing either from muscle memory or hunt-and-peck will most of the time ignore it until it's to late.
Ignoring the capslock is a much better strategy, and it outweighs the marginal benefit of easing out an ALL CAPS password (which is not much better than an all lowercase one).
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Then they are not good security people. The weakest link in security is most often the human element; if you don't understand humans well, it's impossible to build a secure system, no matter how much of a cryptographer wizard you are. How good is the best encryption scheme if its user is socially engineered to unlock it for you?
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
I guess ignoring caps lock (or showing indicator) will not work for web pages. OTOH, how often does it happen? Then the people type in the password a second time, so what.
You've never heard about death by a thousand papercuts?
Every single misstep caused by a user interface makes people mistrust technology; and the effects are cumulative. This carelessness by developers is what makes end users badmouth tech and think it's too complicated.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
No, here you use the word "exact" but you left out the equivocation. Here, you're completely wrong. Above, you were wrong because you were using a non-standard value of the word "correct." Here, with the bare unaltered word, you're just being a tool.
Now you're wrong about what "exact" means and what "correct" means.
If you type exactly the same thing 2 times, they're the same. If you change a "system mode" that determines the value of the keys pressed, and then press the same keys, then you typed something different. And indeed, you even press a key to change that system mode, so it isn't even the same keys pressed.
You try to play semantic games with the words, but you have to choose words within your vocabulary for that to work.
So, basically getting rid of uppercase letters essentially shortens your effective password by 2 letters? OK, makes sense.
On the subject of dictionary based sequences of words - how much entropy would be added if you deliberately misspelled one of the words in the password phrase? Would you get the entire sequence of characters for entropy in that case - 26^42 in your example, since the codebreaker would have to go back to fully brute force? (I get 2 x 10^59)