Good luck using your new password



  • Sooo, I went to reset a user's password in one of our applications today. It presents a single field to enter the new password, then upon hitting [Enter] it pops up a new window to confirm. Out of habit from all of our other apps, I instead hit [Tab] after putting in the temporary password. When the new window didn't pop open after a few moments, I recalled my goof but fortunately checked the number of *'s in the password field before hitting [Enter]; it accepted the tab character as part of the password. You can see where this is going, can't you...  On the actual logon page, [Tab] cycles through the available fields and is never accepted as a character.



  • Well, at least you now know what to do when a user is annoying. ;-)



  • I love tag abuse...I occasionally tag my own posts with "tag abuse"...or something like that. It's a little cheeky, but still fresher than quoting the captcha or making wooden table jokes.



  • What's worse is the opposite: when a system tells you that your password can't have a certain character in it.

     I don't mean like ♥ or anything. I mean like a period, semicolon, or space.

    Which indicates to you that: No, the system is not merely hashing your input and storing it in a database somewhere to be compared to at a later time, or at least protecting it with reversable encryption.

    No, the designers of the system are passing your bare password into an API that is going to potentially parse the password as part of a larger construct, in which certain characters could trip up the parsing of that argument string. Why else would they feel the need to input validate the password? Clearly a bug showed up in testing where passwords with certain characters caused issues in some subsystem... :-(

    Your password is passed on the command line to some program. Or it's being interpolated into a non-parameterized SQL query. Or worse.

    It makes you wish you didn't use the same password for your bank website or email.
     



  • @kirchhoff said:

    What's worse is the opposite: when a system tells you that your password can't have a certain character in it.

     I don't mean like ♥ or anything. I mean like a period, semicolon, or space.

    Which indicates to you that...

    ...the system in question is also available through some other method where inputting certain characters is impossible/impractical (such as mobile devices) or else has to integrate with some legacy system.

    I've developed one where the former applied, and work with another where the latter does.

    If you're in some wonderful enterprisey state of several different systems interacting, where the choice is between dropping support for a few characters or else have the user remember and enter several passwords, I don't blame people who chose the easier solution.



  • @RayS said:

    ...the system in question is also available through some other method where inputting certain characters is impossible/impractical (such as mobile devices) or else has to integrate with some legacy system.

    I've developed one where the former applied, and work with another where the latter does.

    If you're in some wonderful enterprisey state of several different systems interacting, where the choice is between dropping support for a few characters or else have the user remember and enter several passwords, I don't blame people who chose the easier solution.

    True.

    But the few instances in my recollection made me go 'WTF' precisely because I couldn't think of a good reason why they were like that. They were new systems that were certainly targetting desktop users (public-facing websites with no mobile equivalents... and on what portable/mobile browser can you not enter a period as easily as characters?).

    And these systems didn't have multiple faces. By that I mean there wasn't any way for end users to log into any underlying legacy or otherwise incompatible system, if that were the motivation. What should be done, in such cases, is have the user's master password act as a key from which are derived legacy-compatible passwords that no user ever enters, but is stored, emitted, and updated by the system transparently. This can help smooth over password change requirements as well (if an underlying password needs to change more frequently, it can be done by the system automagically).

     

     


Log in to reply