31

A website "broke" after I changed my password to something like "NÌÿÖÏï£Ø¥üQ¢¨¼Ü9¨ÝIÇÅbÍm". I was unable to log in, and customer service deleted my account and had me create a new one. Does this imply security flaws in the site's code? Should I worry about my credentials?

Obviously I'm using a password manager, and the website only allows me to reserve seats in a cinema, so the credentials are not of much value.

  • 4
    The first example had a definite problem, everyone else is enforcing password policies. But I think a rule like "Every character except '?' is OK" stems from some weird bug they never fixed. – Christian Nov 11 '16 at 14:49
  • 2
    Please restrict your question to the first part (site breaks) then. Site specific restrictions for the password are already handled in Why do some websites and programs restrict password characteristics?, i.e. this part is a duplicate. – Steffen Ullrich Nov 11 '16 at 14:55
  • 11
    What is their stance on single quotes? – Arminius Nov 11 '16 at 14:55
  • 1
    It could also be misguided "sanitization". – CodesInChaos Nov 11 '16 at 15:09
  • 3
    The question has been rephrased to cut out the duplicate – Christian Nov 11 '16 at 15:29
28

Your description is that the site fails to properly validate their input. This (weakly) implies a deep flaw in their code. If your input had simply choked their routine that calls PBKDF2(), then your password hash might not have been reproducible; but I would expect a simple password reset should have been adequate to clear up that problem. Deleting your account might indicate that your account record was corrupt; however, deleting accounts might simply be their response to anyone who has a password problem due to unexpected user input. They might even be trying to actively thwart hackers with this response.

Also, flawed doesn't necessarily mean their site is vulnerable. The defective code would need to be exploitable, and you didn't supply evidence of that. Such evidence might include erratic behavior or inexplicably changed values.

If you decide to press further, perhaps testing individual password characters to isolate the glyph that caused their site to lock your account, know that they would be within their rights to consider those attempts to be a hacking attack. Seek the site owner's permission before experimenting.

Note that if instead of using high-bit-set characters, you construct your password from 16 cryptographically random, high-bit-unset, standard, ordinary, printable ASCII alphanumeric characters, the practical difference to your password's security will be irrelevant.

  • 19
    "Note that high-bit...cryptographic...ordinary, printable ASCII" In other words, if the password is long you don't need to use exotic characters. – Bryan Field Nov 11 '16 at 16:11
  • 7
    @jpaugh, Huh? A 16 byte password with the high bit unset in each has 16 x 7 = 112 bits of entropy. An 8 byte password fully randomized has only 64 bits of entropy. They're not equivalent at all. – Wildcard Nov 12 '16 at 2:47
  • 2
    @Wildcard: 0x00 through 0x1F are not printable ASCII, so your entropy calculation is wrong. – Kevin Nov 12 '16 at 6:24
  • 2
    @Kevin, irrelevant; I didn't say anything about ASCII. I was addressing the previous commenter only. A 16 byte password using 7 bits per byte does not have the same count of permutations as a 8 byte password using 8 bits per byte. So I'm not wrong. (Please refrain from calling people "wrong" until you've actually read precisely what they have written.) – Wildcard Nov 12 '16 at 6:31
  • 4
    @Wildcard: My mistake. Since the answer is about ASCII, your comment is irrelevant and belongs in Chat. – Kevin Nov 12 '16 at 6:34
24

Most likely it means that (like most programs written by Americans) it's never been tested with Unicode characters and you've exposed a bug in their code. It's not a high priority for them to fix, so instead they've just sidestepped the problem by telling you to not do that.

It's strange that customer service deleted and recreated your account instead of resetting the password, but not incredibly worrisome. It could be that they're poorly trained to deal with this situation and that's just the approach they took. It could also be that the bug is also present in the password change feature for some reason (maybe they store something encrypted with your password as a key, and they have to decrypt it then recrypt with the new password?).

A site with these sorts of engineering and testing issues is likely to also have a security flaw or two, but that's a statistical correlation, not something directly implied by the observed bug.

  • 13
    "(like most programs written by Americans)" What do Americans have to do with this? – Lightness Races in Orbit Nov 11 '16 at 18:56
  • 21
    @LightnessRacesinOrbit: You do know what the A in ASCII stands for, right? :) Seriously, developers from other countries are far more likely to test their software with non-ASCII characters, just because they use them in their everyday communication. Heck, even the British at least have the £ sign on their keyboards. – Ilmari Karonen Nov 11 '16 at 19:04
  • 21
    In case anyone is wondering, I'm an American, and also rarely test any of my inputs with non-ASCII characters. This isn't a judgement so much as an observation gained from working in the US software industry. – Xiong Chiamiov Nov 11 '16 at 21:55
  • Comments are not for extended discussion; this conversation has been moved to chat. – Jeff Ferland Nov 12 '16 at 15:01
3

Password processing should be one module that does not produce or verify more than a hash. The only ways in which a complex password cannot be successfully reentered is two separate pieces of code supposed to be doing the same thing but not doing so, or worse, passwords getting stored in plain text.

The more processing or storing is done to passwords in the clear, the more susceptible the site is for password extraction attacks or general attacks on the system.

There is an xkcd comic about password processing exceeding its immediate scope.

And of course this also is reminiscent of little Bobby Tables.

Summarizing both comic strips: sanitize input before storing it anywhere, and don't overprocess passwords.

I am sorry if my references are all by Randall Munroe but his explanations are so graphic...

1

It's probably a bug. One rule of thumb is never trust any 3rd party website as anything is possible. Don't assume anything is impossible, but certainly use a complex password but with ASCII characters only.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.