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.

TRiG
  • 609
  • 5
  • 14
Christian
  • 453
  • 4
  • 9
  • Do all these sites really have problems with your password (i.e. crash or similar) or do they only restrict how the password should look like but don't break if you enter a password not conforming to the rules? – Steffen Ullrich Nov 11 '16 at 14:44
  • 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?](http://security.stackexchange.com/questions/1534/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
  • @Christian Thanks! Having two questions in one can be even less productive than duplicates, depending on how the wording and the discussion goes. – jpaugh Nov 12 '16 at 01:02
  • What site is it? Just to make sure I never use it. – André Borie Nov 13 '16 at 00:04
  • @AndréBorie: It's a big cinema in Karlsruhe. You probably won't... Thanks for the answers! – Christian Nov 14 '16 at 11:38

4 Answers4

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.

grochmal
  • 5,677
  • 2
  • 19
  • 30
John Deters
  • 33,650
  • 3
  • 57
  • 110
  • 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. – 700 Software Nov 11 '16 at 16:11
  • @GeorgeBailey, yeah, I was just trying to match his original (now deleted) description of his password as containing "high ANSI characters". – John Deters Nov 11 '16 at 20:48
  • @JohnDeters, Since each additional bit doubles the number of permutations, you can say it more precisely: A 16 byte-long password using 7-bits (high bit-unset) in each character is equivalent to an 8 byte-long password which uses the 8th bit freely as well. – jpaugh Nov 12 '16 at 01:05
  • 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 02:47
  • 2
    @Wildcard: 0x00 through 0x1F are not printable ASCII, so your entropy calculation is wrong. – Kevin Nov 12 '16 at 06: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 06:31
  • 4
    @Wildcard: My mistake. Since the *answer* is about ASCII, your comment is irrelevant and belongs in Chat. – Kevin Nov 12 '16 at 06:34
  • 2
    Don't overlook the very likely possibility that customer service just doesn't have any idea how to fix the issue and saw deleting and recreating the account as the simplest fix. – chrylis -cautiouslyoptimistic- Nov 12 '16 at 22:33
  • @Wildcard but when you calculate 8x8=64, isn't it very relevant that your 8-byte character set only includes 95+120 (approx) = 215 printable characters, not 256? log2(215^8) = 62. So it's 62 bits of entropy instead of 64. Am I right? – Buttle Butkus Nov 16 '16 at 22:22
  • Guys, let it go. Someone above made an error assuming the length and strength of a certain password size, and people jumped on each other over it, but the math isn't the important part here. The important point is to recognize that all passwords that exceed 80 bits of entropy provide the same functional strength to the defender - nobody's going to brute force your passwords if they actually contain 80 bits of entropy. Therefore trying to tweak password rules to increase entropy above 80 bits is a complete waste of time. – John Deters Nov 16 '16 at 23:03
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.

Xiong Chiamiov
  • 9,384
  • 2
  • 34
  • 76
  • 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](http://chat.stackexchange.com/rooms/48390/discussion-on-answer-by-xiong-chiamiov-should-i-trust-a-website-which-breaks-whe). – 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...

user130351
  • 31
  • 1
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.

avi
  • 21
  • 2