"special characters" in passwords: defined how?
-
englebart said:
I interpret the big red X in your screen capture to mean that those are the only allowed characters!
But if you read the text after the red x it says “any characters except the following” and I had tried one of the ones from the list and it rejected my password.
englebart:
Deny lists” never stand the test of time.
Agree :thumbsup:
-
I recently signed up for an account on a very large investment / bank platform and they have the following password requirements (which are mostly stupid) -- see snapshot[^] The requirement I'd like to talk about (which is obviously arbitrary) is :
Special characters except for # & * < > ( ) ' [ ]
Also, note, there aren't too many "special chars" left after all those are removed. :sigh: This is obviously arbitrary and the developers of that site & the password requirements decided not to allow common characters which would cause them problems when parsing the password string. I'm wondering what constitutes a "special character"? 1. Above ascii 127 (even though surely sites use UTF-8 character encoding now? 2. If that is true, then would any emoji (🤖🦍🦄😻👻) count as a "special char"? 3. Anything that isn't alphanumeric? 4. Arbitrary : defined by each site you visit. DING! DING! DING! We have us a winner!!! :laugh: Length, Most Important Password Requirement They have a max of 20 which is ridiculous. I'm guessing that is related to the algorithm they use to parse your incoming password -- especially since the last requirement is:
No sequences (e.g. 12345 or 111)
I'm guessing that since extremely long passwords would take their algorithm longer to search for sequences they decide not to allow long passwords. :| Doesn't pass the sniff test. :rolleyes:
Doesn't the BIG RED 'X' in front of "
Quote:
Special characters except for # & * < > ( ) ' [ ]
mean that you can use THOSE special characters, but none other?
-
No, it makes no sense to limit passwords to a shortened length. Here is why: 1. You cleartext password is __never__ stored so it's length doesn't matter. 2. Your cleartext password is hashed before it is stored at the site you're logging into (probably SHA256) and that means that it is 32 bytes long when it is stored. A SHA256 hash is always EXACTLY 32 bytes long (neither shorter nor longer). So the site never has to worry about max length. If the site does store your cleartext password it would be a terrible security problem. So, why would they ever want to know anything about your password before it is hashed? Well, they are attempting to insure you are not using a weak password which already has an obvious SHA256 hash that hackers know. Google and Microsoft allow 64 character passwords and my passwords for those accounts are that long -- since they are often used for SSO (single sign on) which allows you to sign into many sites. Meaning that you want to keep those accounts very secure so longer is always better.
-
Doesn't the BIG RED 'X' in front of "
Quote:
Special characters except for # & * < > ( ) ' [ ]
mean that you can use THOSE special characters, but none other?
That's interesting, because someone else thought that also. But, notice that the message next to it says, "Special characters except for
Also, I had tried to use one of the ones listed which is how I got the warning. So, they obviously have a confusing message along with the other problems they have. -
I recently signed up for an account on a very large investment / bank platform and they have the following password requirements (which are mostly stupid) -- see snapshot[^] The requirement I'd like to talk about (which is obviously arbitrary) is :
Special characters except for # & * < > ( ) ' [ ]
Also, note, there aren't too many "special chars" left after all those are removed. :sigh: This is obviously arbitrary and the developers of that site & the password requirements decided not to allow common characters which would cause them problems when parsing the password string. I'm wondering what constitutes a "special character"? 1. Above ascii 127 (even though surely sites use UTF-8 character encoding now? 2. If that is true, then would any emoji (🤖🦍🦄😻👻) count as a "special char"? 3. Anything that isn't alphanumeric? 4. Arbitrary : defined by each site you visit. DING! DING! DING! We have us a winner!!! :laugh: Length, Most Important Password Requirement They have a max of 20 which is ridiculous. I'm guessing that is related to the algorithm they use to parse your incoming password -- especially since the last requirement is:
No sequences (e.g. 12345 or 111)
I'm guessing that since extremely long passwords would take their algorithm longer to search for sequences they decide not to allow long passwords. :| Doesn't pass the sniff test. :rolleyes:
raddevus wrote:
when parsing the password string
There's the problem. If a site can't state the policy in a single non-run-on sentence I would avoid it. Extravagant parsing or using regular expressions to validate a user's password seems over-engineered.
Software Zen:
delete this; -
raddevus wrote:
when parsing the password string
There's the problem. If a site can't state the policy in a single non-run-on sentence I would avoid it. Extravagant parsing or using regular expressions to validate a user's password seems over-engineered.
Software Zen:
delete this;Gary Wheeler wrote:
Extravagant parsing or using regular expressions to validate a user's password seems over-engineered.
Agree 100%! I don't understand why they don't just: 1. hash your plaintext password. 2. compare it to known bad password hashes 3. if it matches any of the known bad, then reject, otherwise store your hash and be done Why they looking at my password so closely, anyway? :rolleyes:
-
What bugs me just as much: In an input field for phone number or bank account / credit card number, and they accept digits only. There is a convention for writing credit card numbers as 1234 2345 3456 4567 - not as 1234234534564567, which makes it a lot harder to detect a typo. Bank account numbers are written as 1234 56 7890, or sometimes as 1234.56.7890. Again: 1234567890 makes it much harder to verify. Phone numbers are 404 55 606, not 40455606 (and today, you see phone numbers up to 14 digits, even domestic ones, making it even harder to detect a typo). If they really insist on handling a structured number as a singe long integer, those 'readability spaces' can be removed by a single program code line, in several commonly used text processing tools/libraries. It takes a lot more effort to display an error message box declaring 'Spaces are not permitted in phone numbers' (or whatever). While the number of sites rejecting 'readability spaces' seems to be declining, I have seen an increase in another 'facility' that I wouldn't say 'bugs' me, it rather amuses me: Entry fields for phone or account numbers with a spin button. As when I typed the wrong account or phone number, and really would like to spin from the mistyped number to the correct one. This started long before the AI wave, so don't blame AI!
trønderen wrote:
What bugs me just as much: In an input field for phone number or bank account / credit card number, and they accept digits only
I found a product that I really wanted. The order form would not accept 16 digits. Too long it said. So I copied the page locally, hacked it, then submitted my order. Far as I can recall I got it.
-
That's interesting, because someone else thought that also. But, notice that the message next to it says, "Special characters except for
Also, I had tried to use one of the ones listed which is how I got the warning. So, they obviously have a confusing message along with the other problems they have.The closer you look, the worse it gets!
-
trønderen wrote:
What bugs me just as much: In an input field for phone number or bank account / credit card number, and they accept digits only
I found a product that I really wanted. The order form would not accept 16 digits. Too long it said. So I copied the page locally, hacked it, then submitted my order. Far as I can recall I got it.
-
The closer you look, the worse it gets!
