So, it's long been my belief that, from a UX perspective, it's better to stop a user from doing the wrong thing than checking input after the fact to make sure it's valid.
So the case of disabling a button because it shouldn't be pressed given the state of the application/form/whatever is, to me, a good thing.
But, you have to provide clear indications so the user knows how to resolve the situation. Anything else is actively user hostile.
So:
Do prevent the user from entering bad data instead of allowing them to input it and then telling them it's wrong after the fact.
But don't make it impossible for the user to resolve the situation by providing unclear indications or unreasonable hoops that need to be jumped through.
Random aside: notifying the user they've selected a bad password is, to me, a good thing. Actively preventing the user from enter a bad password, though, is a PITA... sometimes I really just don't care about password security (one-time login, low consequence if hacked, etc).
Slightly tangent to the random aside, but actively preventing the user from entering a bad password is very often bad because 99% of people implementing such a check have no idea what constitutes a good password, and the check actually enforces a bad one.
I especially get mad at absurdly small (<200 chars) maximum lengths; a response of "but we require special characters" is bull. Increasing the size of the character space increases entropy by O(n^k) (polynomial); increasing the length increases entropy by O(k^n) (exponential). Anyone who's taken an undergrad algorithms course or even AP Comp Sci should understand this.
I use the complete works of shakespeare as my passphrase. The rhyming makes it easy to remember. You just need to type deliberately as not to make a typo.
I actually used an entire paragraph from _Alice in Wonderland_ once. If I did it again, I might just make it Alice in Wasteland.
How doth the little tronodile
Improve his clanking tail,
And pour the glowing hobo bile
On every stainless scale!
How cheerfully he seems to grin,
How neatly spreads his claws,
And welcomes desert rangers in
With gently smiling jaws!
Alas, your password must also contain a number, and it exceeds the maximum allowed length of 24 characters.
...and "increasing the character set" actually means "reducing the password space". A rainbow algorithm for instance no longer has to test any plain words at all; just the ones with vowels replaced by digits and/or a special character added to the end. Its actually LESS entropy.
What really pisses me off (looking at you, Skype) is when adding text to a password makes it no longer valid. In other words, bvclkk27 passes validation, but bvclkk27skype doesn't.
So. Frustrating. The second is strictly a stronger password than the first.
56, actually. It's a major shortcoming of bcrypt, and an argument in favour of algorithms like scrypt and PBKDF2.
If you're committed to bcrypt, you could make an argument in favour of digesting the password with something like SHA384 first. That reduces entropy, but (a) it's strictly better than straight SHA, which is what a concerning number of people use already, and (b) it means that you're not messing up the user's pattern/mnemonic if they've got one going.
A counter example, at least for me. I hate Hate HATE forms that try to force me to type a date, phone number, credit card number, etc into some specifically formatted form and prevent me from typing letters. Why?
Problem #1: I type often. My fingers know when I've made a mistake and correct it immediately. But on a number only input field I type 456A<del>7 and because the form wasn't letting me type letters I get just 457 instead of 4567. Now I have to correct yet another mistake that was forced on me
Problem #2: Delete almost never works correctly. There's a CC form [xxxx][xxxx][xxxx][xxxx]. I type want to type 123456789... I type 1235<del>4. I now have [1235][4...] instead of [1234][....]
Problem #4: Paste almost never works. I have my info somewhere. I copy 123456789... I paste I get [1234][....][....][....] or I copy 1234-5678-9... and paste and I get an error. "No dashes allowed" or I get some other crap.
Problem #5: Copy rarely works because I can't select all fields since they've been separated.
Problem #6: 95%-99% of the time tab goes to the next place in the form but many custom forms move to the next field automatically so I type a phone number 111-222-3333 and then press tab but because the custom form assumed the moment I typed the last 3 that it would be helpful to automatically go the next field I'm now two fields ahead.
You could possibly fix #2, #4 and #5 but I'd prefer just a blank field, no mucking with the input system. If you want to display some live status while I'm typing just outside the form on whether my input is correct or not yet that's fine but please don't mess up my typing muscle memory.
I'd be really curious if anyone has done any serious testing on these fancy custom input "helpful" forms vs simpler plain text areas.
Yet another is how about just accepting the user's input and checking if it could be what you need. For example when taking a CC card, let me type WWWWXXXXYYYYZZZZ or WWWW XXXX YYYY ZZZZ or WWWW.XXXX.YYYY.ZZZZ or WWWW-XXX-YYYY-ZZZZ or even WWWW XXXX YYYY ZZZZ. Check if you can turn that into 16 digits. If so assume it's correct. Don't force me to do it what's easy for the computer. I might have it in some other format and I want to copy and paste it. Or I might just find it easier to space out because I can then read it and more easily check for mistakes. For example accept a US phone number in XXX-YYY-ZZZZ instead of forcing me to XXXYYYZZZZ
There's especially no good excuse for CC or phone numbers, because they're all numbers. All you have to do is strip out anything that isn't a "significant" character (i.e. a digit or a letter), throw an error if any aren't digits, and throw an error if it isn't the right length. This algorithm is basically guaranteed* to behave exactly the way that everyone expects it to.
What I hate is when you enter in a ton of info into a form and one of those fields is password. You make a mistake on something like the phone number and it wipes out the password field forcing you to type it again only to have the process happen again because it failed to tell you another error in your data.
No, it's a great example. I use a password manager that generates strong random passwords with special characters, but still run into problems on websites:
* My password is too long
* My password doesn't contain one of their required special characters
* My password contains a special character they don't explicitly support
I loathe too long problems - if only because instead of letting me know they silently truncate the password to their maximum! But only on the password change form - the rest of their site accepts the long one for checking.
I now intentionally limit the longest password my password manager will generate to 12 characters now, just to avoid this mess.
Fair point. But for people who are doing these: please put the same instructions what is needed for the password when logging in the later time through normal login process. It might help to remember the password better (at least would help one person on this planet, me).
(edit: fixed typos, not a native english speaker here)
My solution is that I create a password, then promptly forget it. When I want to use that site again, I simply click the "forgot my password" link and create a new one.
Basically, if I don't use a site every day, or it isn't sensitive like banking information, I don't really even have a password.
I am willing to bet that a lot of people are "Login via email" just like me!
Isn't this simply the thinking that is criticized in the article? Not every matter needs a regulation on it that might break another workflow in the meantime.
Yes, distant regulations rarely compose well for unpredictable local workflows. The closer a policy/rule can be to the edge, local to the affected users, the better chance of it being composed into a useful process that can adapt to new circumstances.
Passwords need regulation though. How many people are going to use a common dictionary word, password1, 1234, the name of their cat etc. if they can. Forcing them not to is good for you and good for them.
I don't know what manager you use, but Password Safe allows you to set custom generation rules to each entry. This has mostly been handy because nobody agrees on what set of special characters to support.
I don't like it when computers are used to program people. Your password must have exactly 10 characters etc. is a salient example. Compare that to a better UI like git--really, tell me users don't interact with it--and you'll notice that git lets you make terrible mistakes if you want to, but provides a way to recover. It's interesting that this better approach to passwords[0] resembles the "I forgot my password" feature.
When I implement not-quite-trivial business rules, I usually spend at least two thirds of the time to give good, verbose error messages about which rules are violated, and what to do instead.
Often it would be rather easy to make the check itself a few lines of conditional code or a single SQL query, but then the only response I could give to the user is "you can't do that", plus a link to the requirements document. Instead effort is spent to follow the steps in which a human might check the constraints.
Myst was an example of this, which is why I hated that game. You wondered around this (admittedly beautiful) world with very limited degrees-of-freedom. A button here, a lever there. And when you actuated that DoF anything in the whole fucking world might have changed. Then it was up to you to wander around seeing what changed, and which new DoF's opened up. Wash, rinse, repeat. That was the game of Myst.
If you think about it, the greyed out sharing button (and indeed most infuriating software stories) essentially follow the Myst pattern, but in reverse. An unwanted change has occurred to the state of the world, and you don't know what DoF triggered it.
The password thing is actually a slightly different class of user abuse, embodied by all forms, which is making the user turn messy thoughts into coherent data, which is the essence of work. This data must satisfy a long list of predicates, an invisible gauntlet of tests. (It's even better when the form resets part of itself on error - like when your password is cleared if you don't enter the captcha correctly.)
These are crimes against the user, and truly need to stop. (Although Myst was a big hit so clearly some people really love the abuse.)
I think games like Myst succeed in cases where, when the player changes to the state of the world, the consequences of the change make some kind of sense (be it mechanical, symbolic, imaginative, etc.). If you can follow the wire from the switch to the lamp, then you can reasonably deduce that the switch controls the lamp. If you see a rune in two place, then it's reasonable to draw a connection.
Games (and software!) fail when the connections between elements are too subtle, too complex, or simply too inconsistent, and sorting them out passes from being fun to being work.
That conversation is supposed to seem ridiculous but I'm not kidding when I say, you can have exactly that kind of discussion by calling any number of customer support lines for various corporations. You don't need computers for this kind of idiocy. You simply need a flow chart and a pedant.
Me: My tire is going flat on my rental car.
Avis: OK, we'll send someone out to put on a spare.
Me: That's OK. I can change the spare.
Avis: OK, then after that take it to a nearby location and exchange the car.
Me: I've called all the locations within 45 miles and none have an available car.
Avis: OK, we can bring you a new car.
Me: Great.
Avis: I have to warn you however, that you may be charged for the price of the tow.
Me: What tow?
Avis: We have to tow the car too you.
Me: Why?
Avis: That's how we bring you a car.
Me: Can't someone just drive a new car out and take this one back?
Avis: No both cars must hauled.
Me: Why?
Avis: That's just how it's done.
Me: OK, why would I have to pay for it anyway. The tire has been leaking since I got the car.
Avis: Because the car has a good spare. Can we send someone out to change it?
Me: That's not necessary I can change it.
Avis: OK, then after that you can take it to the nearest Avis and exchange it.
Me: I already told you, all the nearby locations are out of cars.
Avis: OK, then we can tow you out a new car and exchange it.
Me: OK.
Avis: But I have to warn you sir that you may be charged for the tow.
Me: Why?
Me and Avis: Because the car has a good spare.
Me: Are you a robot?
Avis: ....
Me: I ask because I really can't tell if I'm speaking to a human.
Such people populate many call centers. Yet, if you call repeatedly, you will eventually find a competent human who can make an independent decision to solve an "irregular operations" customer problem. You can usually recognize them within the first minute of a conversation -- a modern Turing test.
The future call center may consist of algos with voice synthesizers, and that one competent human :)
I believe it is the desire of many corporations to actually build a human shield between the management, who have authority to fix problems and the customers.
I recently had a rental company tow a new car to me and tow away the old one because the key they gave me was slightly broken and stopped working when it got wet. They had a spare key, and they believed me that the wet key was the obvious problem, but sending a key was just not how it was done.
(I'm kind of getting the feeling I completely failed to understand the point of this article, or am at least misunderstanding the point of the examples...so the following may be WAY off)
He's got a point about it not being clear if "Passwords need 10 characters" means they must be exactly 10 characters long or at least 10 characters long. It is the latter. If you put a password of less than 10 characters in the first password field, when you move on to re-enter the password it will immediately flag the error with the message "Your Password must be at least 10 characters long".
I'm a bit confused, though, by the imaginary dialog between him and two clerks showing how these requirements would work if this were done in person. To reflect the actual form, the dialog should be more like this:
HIM: Here is the password I want. (Hands paper to clerk).
CLERK: Passwords have to have at least one special character from this list. (Gives list to him). Your does not have one of these.
CLERK: Also, passwords can only contain letters, numbers, and characters from the special character list. (Point to the list he just handed over). You have a special character that is not on the list.
HIM: (Replaces the disallowed character with one from the allowed special character list) (Hands new password request to the clerk). OK, try this one!
CLERK: That meets our requirements.
I'm not sure at all where that part of his dialog about question mark being a special character but not a character comes from. The password "Ab345?7890" is accepted by the password checking JavaScript, even though it is exactly 10 characters long and so the ? must be counting as both a special character and as a character.
Don't get me wrong here...I'm not saying these requirements are OK. I find requirements like this annoying, because I use a password manager to generate my passwords. I can easily tell the password manager to include or exclude special characters, but I don't get to pick which special characters it picks from. At a site like the Post Office, which limits the set of special characters, I might have to generate several passwords before I hit one that is acceptable.
As a password manager user, what I really want out of sites is for them to allow long passwords, and place no restrictions on the characters in those long passwords. I will then use 25 character random passwords consisting of digits and lower case letters. That gives me 128 bits of entropy, but if it needs to be manually typed for some reason it is not too bad. I'm OK if they place some character requirements on shorter passwords...but if the password is long enough, let me do what I want.
So yeah, the requirements are annoying. I am just having a hard time believing that the red explanations that appear when the first password field loses focus were not sufficient to enable someone who programs at Google to manage to come up with a password acceptable to the Post Office.
I'd say the Post Office actually did a pretty good job of implementing the form. Most sites just tell you that your password violates the rules, and it is up to you to re-read the full list of rules trying to figure out which ones tripped you. The Post Office form tells you exactly which rules were violated.
The root problem is the arbitrary password requirements of course, but given that that isn't going to change, you might want a better password manager. Keepass for example allows you to specify which "special characters" to use when generating a password.
> Ridiculous password requirements are a subset of a larger problem: computers make it possible to enforce ridiculous rules, and so those ridiculous rules made. If you I to wait in line at the post office to see a clerk who would register me, how would they possibly enforce this?
Why are there words missing in a way that's not typical of the usual non-native speaker drop-outs? I'm finding this article very difficult to read.
My own personal story of rage on this front: a site which, at the time I signed up, permitted arbitrary characters for its "security questions". I had the cheek to include characters other than pure alphanumerics.
Later, I return to this site and need to offer up the answers to the security questions. No problem... right up until I discover that some @$!#^%!!?! software developer put format guards on the security question answer fields at challenge time (vs. creation time). Yes, it was possible to create an answer to the (stupid) security questions which could not be answered by the website.
So now, my access to this site is literally sitting behind a several-months old developer ticket.
I created an account on justin.tv a long time ago and my username was 'grapefuckingjelly'. For awhile I couldn't log in because of a new validation on the log in form for swear words (the validation eventually went away). These days, I constantly hit a screen when logging into twitch.tv to transfer my justin.tv account over. It never seems to work... probably due to some validation.
I tried logging into twitch last night and it kept telling me my username/password are invalid, so I think my account is inaccessible again.
58 comments
[ 4.3 ms ] story [ 116 ms ] threadSo the case of disabling a button because it shouldn't be pressed given the state of the application/form/whatever is, to me, a good thing.
But, you have to provide clear indications so the user knows how to resolve the situation. Anything else is actively user hostile.
So:
Do prevent the user from entering bad data instead of allowing them to input it and then telling them it's wrong after the fact.
But don't make it impossible for the user to resolve the situation by providing unclear indications or unreasonable hoops that need to be jumped through.
Random aside: notifying the user they've selected a bad password is, to me, a good thing. Actively preventing the user from enter a bad password, though, is a PITA... sometimes I really just don't care about password security (one-time login, low consequence if hacked, etc).
(Relevant xkcd: https://xkcd.com/936/)
I especially get mad at absurdly small (<200 chars) maximum lengths; a response of "but we require special characters" is bull. Increasing the size of the character space increases entropy by O(n^k) (polynomial); increasing the length increases entropy by O(k^n) (exponential). Anyone who's taken an undergrad algorithms course or even AP Comp Sci should understand this.
200 chars? Really? Sure, there shouldn't be arbitrary limits, but...
200 chars?
So. Frustrating. The second is strictly a stronger password than the first.
You realize even the well-regarded bcrypt algorithm only hashes 72 characters, right?
If you're committed to bcrypt, you could make an argument in favour of digesting the password with something like SHA384 first. That reduces entropy, but (a) it's strictly better than straight SHA, which is what a concerning number of people use already, and (b) it means that you're not messing up the user's pattern/mnemonic if they've got one going.
Problem #1: I type often. My fingers know when I've made a mistake and correct it immediately. But on a number only input field I type 456A<del>7 and because the form wasn't letting me type letters I get just 457 instead of 4567. Now I have to correct yet another mistake that was forced on me
Problem #2: Delete almost never works correctly. There's a CC form [xxxx][xxxx][xxxx][xxxx]. I type want to type 123456789... I type 1235<del>4. I now have [1235][4...] instead of [1234][....]
Problem #4: Paste almost never works. I have my info somewhere. I copy 123456789... I paste I get [1234][....][....][....] or I copy 1234-5678-9... and paste and I get an error. "No dashes allowed" or I get some other crap.
Problem #5: Copy rarely works because I can't select all fields since they've been separated.
Problem #6: 95%-99% of the time tab goes to the next place in the form but many custom forms move to the next field automatically so I type a phone number 111-222-3333 and then press tab but because the custom form assumed the moment I typed the last 3 that it would be helpful to automatically go the next field I'm now two fields ahead.
You could possibly fix #2, #4 and #5 but I'd prefer just a blank field, no mucking with the input system. If you want to display some live status while I'm typing just outside the form on whether my input is correct or not yet that's fine but please don't mess up my typing muscle memory.
I'd be really curious if anyone has done any serious testing on these fancy custom input "helpful" forms vs simpler plain text areas.
Yet another is how about just accepting the user's input and checking if it could be what you need. For example when taking a CC card, let me type WWWWXXXXYYYYZZZZ or WWWW XXXX YYYY ZZZZ or WWWW.XXXX.YYYY.ZZZZ or WWWW-XXX-YYYY-ZZZZ or even WWWW XXXX YYYY ZZZZ. Check if you can turn that into 16 digits. If so assume it's correct. Don't force me to do it what's easy for the computer. I might have it in some other format and I want to copy and paste it. Or I might just find it easier to space out because I can then read it and more easily check for mistakes. For example accept a US phone number in XXX-YYY-ZZZZ instead of forcing me to XXXYYYZZZZ
*I am not a UX engineer, YMMV
WHY!?!?!
I now intentionally limit the longest password my password manager will generate to 12 characters now, just to avoid this mess.
https://blog.agilebits.com/2015/03/23/an-open-letter-to-bank...
(edit: fixed typos, not a native english speaker here)
Basically, if I don't use a site every day, or it isn't sensitive like banking information, I don't really even have a password.
I am willing to bet that a lot of people are "Login via email" just like me!
Accept that your site isn't special enough to have a unique password and stop being so fucking arrogant.
[0] http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/MASPPapers/EmailA...
Often it would be rather easy to make the check itself a few lines of conditional code or a single SQL query, but then the only response I could give to the user is "you can't do that", plus a link to the requirements document. Instead effort is spent to follow the steps in which a human might check the constraints.
I just got a screen grab from a user asking "What does this mean?" and the error was "Not enough space on disk."
If you think about it, the greyed out sharing button (and indeed most infuriating software stories) essentially follow the Myst pattern, but in reverse. An unwanted change has occurred to the state of the world, and you don't know what DoF triggered it.
The password thing is actually a slightly different class of user abuse, embodied by all forms, which is making the user turn messy thoughts into coherent data, which is the essence of work. This data must satisfy a long list of predicates, an invisible gauntlet of tests. (It's even better when the form resets part of itself on error - like when your password is cleared if you don't enter the captcha correctly.)
These are crimes against the user, and truly need to stop. (Although Myst was a big hit so clearly some people really love the abuse.)
Games (and software!) fail when the connections between elements are too subtle, too complex, or simply too inconsistent, and sorting them out passes from being fun to being work.
You've never played Myst, have you.
Me: My tire is going flat on my rental car.
Avis: OK, we'll send someone out to put on a spare.
Me: That's OK. I can change the spare.
Avis: OK, then after that take it to a nearby location and exchange the car.
Me: I've called all the locations within 45 miles and none have an available car.
Avis: OK, we can bring you a new car.
Me: Great.
Avis: I have to warn you however, that you may be charged for the price of the tow.
Me: What tow?
Avis: We have to tow the car too you.
Me: Why?
Avis: That's how we bring you a car.
Me: Can't someone just drive a new car out and take this one back?
Avis: No both cars must hauled.
Me: Why?
Avis: That's just how it's done.
Me: OK, why would I have to pay for it anyway. The tire has been leaking since I got the car.
Avis: Because the car has a good spare. Can we send someone out to change it?
Me: That's not necessary I can change it.
Avis: OK, then after that you can take it to the nearest Avis and exchange it.
Me: I already told you, all the nearby locations are out of cars.
Avis: OK, then we can tow you out a new car and exchange it.
Me: OK.
Avis: But I have to warn you sir that you may be charged for the tow.
Me: Why?
Me and Avis: Because the car has a good spare.
Me: Are you a robot?
Avis: ....
Me: I ask because I really can't tell if I'm speaking to a human.
Avis: Yes sir, I am a human.
The future call center may consist of algos with voice synthesizers, and that one competent human :)
He's got a point about it not being clear if "Passwords need 10 characters" means they must be exactly 10 characters long or at least 10 characters long. It is the latter. If you put a password of less than 10 characters in the first password field, when you move on to re-enter the password it will immediately flag the error with the message "Your Password must be at least 10 characters long".
I'm a bit confused, though, by the imaginary dialog between him and two clerks showing how these requirements would work if this were done in person. To reflect the actual form, the dialog should be more like this:
HIM: Here is the password I want. (Hands paper to clerk).
CLERK: Passwords have to have at least one special character from this list. (Gives list to him). Your does not have one of these.
CLERK: Also, passwords can only contain letters, numbers, and characters from the special character list. (Point to the list he just handed over). You have a special character that is not on the list.
HIM: (Replaces the disallowed character with one from the allowed special character list) (Hands new password request to the clerk). OK, try this one!
CLERK: That meets our requirements.
I'm not sure at all where that part of his dialog about question mark being a special character but not a character comes from. The password "Ab345?7890" is accepted by the password checking JavaScript, even though it is exactly 10 characters long and so the ? must be counting as both a special character and as a character.
Don't get me wrong here...I'm not saying these requirements are OK. I find requirements like this annoying, because I use a password manager to generate my passwords. I can easily tell the password manager to include or exclude special characters, but I don't get to pick which special characters it picks from. At a site like the Post Office, which limits the set of special characters, I might have to generate several passwords before I hit one that is acceptable.
As a password manager user, what I really want out of sites is for them to allow long passwords, and place no restrictions on the characters in those long passwords. I will then use 25 character random passwords consisting of digits and lower case letters. That gives me 128 bits of entropy, but if it needs to be manually typed for some reason it is not too bad. I'm OK if they place some character requirements on shorter passwords...but if the password is long enough, let me do what I want.
So yeah, the requirements are annoying. I am just having a hard time believing that the red explanations that appear when the first password field loses focus were not sufficient to enable someone who programs at Google to manage to come up with a password acceptable to the Post Office.
I'd say the Post Office actually did a pretty good job of implementing the form. Most sites just tell you that your password violates the rules, and it is up to you to re-read the full list of rules trying to figure out which ones tripped you. The Post Office form tells you exactly which rules were violated.
Why are there words missing in a way that's not typical of the usual non-native speaker drop-outs? I'm finding this article very difficult to read.
Later, I return to this site and need to offer up the answers to the security questions. No problem... right up until I discover that some @$!#^%!!?! software developer put format guards on the security question answer fields at challenge time (vs. creation time). Yes, it was possible to create an answer to the (stupid) security questions which could not be answered by the website.
So now, my access to this site is literally sitting behind a several-months old developer ticket.
I tried logging into twitch last night and it kept telling me my username/password are invalid, so I think my account is inaccessible again.