6 ms·

Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storin

by pwg 10y ago

Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. Why: Because if they were (at least) hashing it the output from the hash would be a binary string in which case they would have to be 8-bit clean through to the DB column where the hash output resided, and then there would be no reason to care what character was in the input. Caring specifically about a + in a password also implies that their authentication might be setup internally as a http endpoint with URL encoding of a "password=" form variable (because + is used as the escape for hex encoded characters in URL encoding). Both, of course, imply a lack of proper secure design in their password handling.

lstamour 10y ago
Sadly at some places it's intentional so your password matches existing PIN systems or is "easy to remember" so you're not as easily locked out of your account. I wish in those cases there was a check box that says, "I know what I'm doing, leave me alone." Speaking of annoying validations, my name has a hyphen in it but you'd be surprised how often that's rejected with the familiar, "Please enter a valid last name." Sigh.
- girvo 10y ago
  My partner has a hyphenated first and last name. So many systems refuse to accept that, and even regular humans struggle with understanding it!
  - moosterv 10y ago
    My last name starts with oo, which many humans struggle to understand. It almost always becomes do, or co.
  - kasparsklavins 10y ago
    Had this bug in a system I was working on. Pushed a patch in april.. and there still is an ongoing discussion whether it should be merged or not.
    - int_19h 10y ago
      Why is there a discussion? What do the people who don't want to take the patch say? "We don't care if we lose customers with unusual names"?
      - kasparsklavins 10y ago
        Because of code style (I do not mean spaces or tabs, it is beyond that). Different developers have different ideas of how a function should behave, where it literally has no effect on how the rest of the system works.
kiallmacinnes 10y ago
Or, they submit the password over HTTPS, validate server side, then hash and store in the DB? There is no reason to assume rejecting of a + means they don't hash, and browsers escape the password for you in POST/GET etc. The fact that + is used for space really isn't relevant. (That said, I think it's pretty stupid to "validate" passwords beyond checking for "12345", "password", a min length, and other public info. e.g. your password should not be your name or date of birth. Anything any password generator spits out, so long as it meets the min length criteria, should be accepted).
- Freak_NL 10y ago
  > Anything any password generator spits out, so long as it meets the min length criteria, should be accepted It annoys me to no end when I have to hand-craft a password to stay within the silly rules of some service. Be vocal about this! Keep complaining to the services you use that don't accept such valid passwords. Banks for example are notorious in insisting on short passwords and arcane limits on which characters to use (ING in the Netherlands limits you to 20 characters, and nobody there seems to be able to explain why).
  - garaetjjte 10y ago
    With banks there is other problem, because they often use partial passwords. They are password manager unfriendly and often limited to 16 characters.
    - erelde 10y ago
      Société Générale uses the client ID and a 6 digit passnumber (sent via physical mail) with a digital numpad (you have to click) where each number is randomly placed. So secure. And they force a change every 3 months. As if a new 6 digit pass was more secure than the last 6 digit pass. [https://en.wikipedia.org/wiki/Société_Générale https://en.wikipedia.org/wiki/Société_Générale]
brianwawok 10y ago
> Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. I don't think that is true at all. I may very well want to put a few simple rules I validate serverside, such as 1) No username in password 2) No email in password 3) No list of 100 most common passwords in password All of which require me to look at the text for your password, none of which mean I am storing it in plaintext.
- justinpombrio 10y ago
  All of those checks can easily be done client-side, though. Of course this means you can't guarantee that none of these rules are violated, but I suspect that the users capable of bypassing this aren't the ones you're concerned about anyways.
  - adrusi 10y ago
    The server does have to have access to the plain text password in memory, you know. I don't see why you think it's worth sacrificing guarantees of password strength to uphold some kind of taboo.
    - arielb1 10y ago
      No it doesn't. You can perform the first pass of salted hashing on the client-side. This should not harm security, but it can improve it if someone on the datapath is logging requests but does not alter them.
      - warfangle 10y ago
        Isn't that what SSL does? And if the SSL between you and the destination is compromised, you don't even know if the hashing algorithm you asked the client to use is actually the one they used.
        10y ago
seanp2k2 10y ago
For more fun, try putting a "--" (two consecutive hyphens) in many fields in the AWS console. Not allowed, I guess because they're passing it to shell commands somewhere along the line?!
- alcari 10y ago
  Not likely. That's the comment start marker in many dialects of SQL. For commands, shell metacharacters like `, |, &, and $() are much more important.
viraptor 10y ago
As much as I agree that most artificial limits on the passwords are silly, there's a reason for at least limiting to latin1 charset - or maybe even a bit stricter. How sure are you that strings are always unified the same way between the browser and hashing? Have you tested that you can login from a browser which prefers CJK encodings and each of the UTFs? From all browsers? Maybe it works, maybe your framework deals with this without issues. But if not, do you really want to chase those mysteries in the future? Btw, almost nobody is actually storing hashes as binary blobs. Pretty much every framework I know stores either base64, or direct hex encoding of the value.
- kccqzy 10y ago
  We reject Unicode control characters, surrogates, private use code points etc. Passwords are sent in a UTF-8 encoded JSON over TLS. They are normalized using NFC.

by pwg 10y ago

lstamour 10y ago

Sadly at some places it's intentional so your password matches existing PIN systems or is "easy to remember" so you're not as easily locked out of your account. I wish in those cases there was a check box that says, "I know what I'm doing, leave me alone." Speaking of annoying validations, my name has a hyphen in it but you'd be surprised how often that's rejected with the familiar, "Please enter a valid last name." Sigh.

girvo 10y ago
My partner has a hyphenated first and last name. So many systems refuse to accept that, and even regular humans struggle with understanding it!
- moosterv 10y ago
  My last name starts with oo, which many humans struggle to understand. It almost always becomes do, or co.
- kasparsklavins 10y ago
  Had this bug in a system I was working on. Pushed a patch in april.. and there still is an ongoing discussion whether it should be merged or not.
  - int_19h 10y ago
    Why is there a discussion? What do the people who don't want to take the patch say? "We don't care if we lose customers with unusual names"?
    - kasparsklavins 10y ago
      Because of code style (I do not mean spaces or tabs, it is beyond that). Different developers have different ideas of how a function should behave, where it literally has no effect on how the rest of the system works.

kiallmacinnes 10y ago

Or, they submit the password over HTTPS, validate server side, then hash and store in the DB? There is no reason to assume rejecting of a + means they don't hash, and browsers escape the password for you in POST/GET etc. The fact that + is used for space really isn't relevant. (That said, I think it's pretty stupid to "validate" passwords beyond checking for "12345", "password", a min length, and other public info. e.g. your password should not be your name or date of birth. Anything any password generator spits out, so long as it meets the min length criteria, should be accepted).

Freak_NL 10y ago
> Anything any password generator spits out, so long as it meets the min length criteria, should be accepted It annoys me to no end when I have to hand-craft a password to stay within the silly rules of some service. Be vocal about this! Keep complaining to the services you use that don't accept such valid passwords. Banks for example are notorious in insisting on short passwords and arcane limits on which characters to use (ING in the Netherlands limits you to 20 characters, and nobody there seems to be able to explain why).
- garaetjjte 10y ago
  With banks there is other problem, because they often use partial passwords. They are password manager unfriendly and often limited to 16 characters.
  - erelde 10y ago
    Société Générale uses the client ID and a 6 digit passnumber (sent via physical mail) with a digital numpad (you have to click) where each number is randomly placed. So secure. And they force a change every 3 months. As if a new 6 digit pass was more secure than the last 6 digit pass. [https://en.wikipedia.org/wiki/Société_Générale https://en.wikipedia.org/wiki/Société_Générale]

brianwawok 10y ago

> Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. I don't think that is true at all. I may very well want to put a few simple rules I validate serverside, such as 1) No username in password 2) No email in password 3) No list of 100 most common passwords in password All of which require me to look at the text for your password, none of which mean I am storing it in plaintext.

justinpombrio 10y ago
All of those checks can easily be done client-side, though. Of course this means you can't guarantee that none of these rules are violated, but I suspect that the users capable of bypassing this aren't the ones you're concerned about anyways.
- adrusi 10y ago
  The server does have to have access to the plain text password in memory, you know. I don't see why you think it's worth sacrificing guarantees of password strength to uphold some kind of taboo.
  - arielb1 10y ago
    No it doesn't. You can perform the first pass of salted hashing on the client-side. This should not harm security, but it can improve it if someone on the datapath is logging requests but does not alter them.
    - warfangle 10y ago
      Isn't that what SSL does? And if the SSL between you and the destination is compromised, you don't even know if the hashing algorithm you asked the client to use is actually the one they used.
      - 10y ago

seanp2k2 10y ago

For more fun, try putting a "--" (two consecutive hyphens) in many fields in the AWS console. Not allowed, I guess because they're passing it to shell commands somewhere along the line?!

alcari 10y ago
Not likely. That's the comment start marker in many dialects of SQL. For commands, shell metacharacters like `, |, &, and $() are much more important.

viraptor 10y ago

As much as I agree that most artificial limits on the passwords are silly, there's a reason for at least limiting to latin1 charset - or maybe even a bit stricter. How sure are you that strings are always unified the same way between the browser and hashing? Have you tested that you can login from a browser which prefers CJK encodings and each of the UTFs? From all browsers? Maybe it works, maybe your framework deals with this without issues. But if not, do you really want to chase those mysteries in the future? Btw, almost nobody is actually storing hashes as binary blobs. Pretty much every framework I know stores either base64, or direct hex encoding of the value.

kccqzy 10y ago
We reject Unicode control characters, surrogates, private use code points etc. Passwords are sent in a UTF-8 encoded JSON over TLS. They are normalized using NFC.