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, 2016 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. Nov 11, 2016 at 14:55
  • 11
    What is their stance on single quotes?
    – Arminius
    Nov 11, 2016 at 14:55
  • 1
    It could also be misguided "sanitization". Nov 11, 2016 at 15:09
  • 3
    The question has been rephrased to cut out the duplicate
    – Christian
    Nov 11, 2016 at 15:29

4 Answers 4


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. Nov 11, 2016 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, 2016 at 2:47
  • 2
    @Wildcard: 0x00 through 0x1F are not printable ASCII, so your entropy calculation is wrong.
    – Kevin
    Nov 12, 2016 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, 2016 at 6:31
  • 4
    @Wildcard: My mistake. Since the answer is about ASCII, your comment is irrelevant and belongs in Chat.
    – Kevin
    Nov 12, 2016 at 6:34

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? Nov 11, 2016 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. Nov 11, 2016 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. Nov 11, 2016 at 21:55
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jeff Ferland
    Nov 12, 2016 at 15:01

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...


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .