|
"The Pepsi Syndrome" -- an SNL sketch circa 1980
|
|
|
|
|
Take it in the shower with you and wash it out. Then dry.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
This is actually not a bad suggestion. As long as you allow it to dry completely before applying any power to it.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
posted because it worked for me.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
|
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
I believe a Trojan can prevent such problems.
|
|
|
|
|
#Worldle #637 3/6 (100%)
π©π©π¨β¬β¬β¬
οΈ
π©π©π¨β¬β¬β‘οΈ
π©π©π©π©π©π
https://worldle.teuteuf.fr
no map needed
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Wordle 854 3/6
β¬π¨β¬β¬β¬
π©β¬β¬π©β¬
π©π©π©π©π©
|
|
|
|
|
Wordle 854 5/6
β¬β¬π©β¬β¬
π©β¬π©β¬β¬
π©β¬π©β¬π©
π©β¬π©π©π©
π©π©π©π©π©
All green π.
|
|
|
|
|
Wordle 854 4/6*
β¬π¨β¬π¨β¬
π©β¬π¨π¨β¬
π©β¬π©π©π©
π©π©π©π©π©
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
β¬π¨β¬β¬β¬
β¬π¨β¬β¬π¨
π©β¬π©π©β¬
π©π©π©π©π©
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 854 4/6
π©β¬β¬π¨β¬
π©β¬π©β¬β¬
π©β¬π©β¬β¬
π©π©π©π©π©
|
|
|
|
|
Wordle 854 2/6
π¨β¬π©β¬π¨
π©π©π©π©π©
Got it in a rare two!
|
|
|
|
|
Wordle 854 6/6
β¬β¬β¬π¨β¬
π¨β¬β¬β¬π¨
β¬π¨π©π¨β¬
π©β¬π©π©β¬
π©β¬π©π©π©
π©π©π©π©π©
βThat which can be asserted without evidence, can be dismissed without evidence.β
β Christopher Hitchens
|
|
|
|
|
Wordle 854 3/6
β¬β¬β¬β¬β¬
π©β¬π©π©π©
π©π©π©π©π©
|
|
|
|
|
Wordle 854 4/6
β¬β¬β¬β¬β¬
β¬π¨π©π¨β¬
π©β¬π©π©β¬
π©π©π©π©π©
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 854 5/6
β¬β¬β¬β¬β¬
π©β¬π¨β¬β¬
π©β¬β¬π©β¬
π©β¬π©β¬π©
π©π©π©π©π©
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
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.
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!!!
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.
|
|
|
|
|
I just counted the special characters on my keyboard - 32 of them. The bank isn't allowing 10 of them.
123456789 123456789 123456789 12 <= Counter
`~!@#$%^&*()_-+={[}]|\:;"'<,>.?/
Their allowable character set contains 74 characters. The issue is many people forget about some of the common characters that aren't alphabetic and only think about the characters on the top row of the keyboard.
|
|
|
|
|
Very good point. I agree with that.
I'm still interested in why those particular characters are "special characters"
Just because they appear on my keyboard?
This means that
1. their algorithm probably contains an array with the non-allowed characters.
2. they compare each char in your password string to the array ala nonAllowedChars.Contains(password[i])
Seems interesting. Also, of course, there is apparently no standard for what is a "special char".
They could just:
1. hash whatever you sent
2. compare hash to known bad password hashes - deny if fails and allow if passes
I don't know. It seems odd that they look at cleartext password.
|
|
|
|
|
Some of those "invalid" characters are used as "escape" characters in character codes, strings, and HTML / XML.
(I can't show examples because they "get escaped" here)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: Some of those "invalid" characters are used as "escape" characters in character codes, strings, and HTML / XML
I agree with this also, but I also know that converting text input to Base64 to pass it across the line is extremely easy. You would hope they would just :
1. take the cleartext input
2. convert to base64
3. send base64
4. convert back to UTF-8 on server side.
5. hash the cleartext
6. look up the hash to see if it matches known bad passwords
7. if it matches bad, reject, if not then save it as the user's hash.
Next when user logs in, just hash their cleartext and match it to what the user's hash should be.
|
|
|
|
|
The (extra) handling of said characters is another topic.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
raddevus wrote: 4. convert back to UTF-8 on server side. Well, UTF-8 isn't 'cleartext', but a multi-byte encoding of a 32-bit character code. There aren't very many applications around prepared to handle 32 bit character codes.
At least in the Western world, the common approach is to go for 16 bit UTF-16 codes internally - and for those falling outside that range, say 'To heck with those'. Even if you are not prepared to handle those UTF-16 codes pointing you over to the more exotic characters, you will be able to handle almost all the textual information you are likely to encounter, regardless of language.
In the age of 16-bit Windows, the 8-bit ISO 8859 encoding was the standard (with a few Window specific extensions). Since the advent of 32 bit Windows, UTF-16 has been the standard internal representation - although you shouldn't rely firmly on all applications to handle anything outside the 'Basic plane' (the first 64 kibi characters). (I would never trust that to be true for any *nix application without thorough testing!)
So: If the application on the server side is prepared for 16 bit characters, most likely according to UTF-16, you are probably fine. (Full 32-bit UTF is a non-essential 'nice to have'-feature.) An ability to accept and forward UTF-8 as a byte stream is not sufficient unless you can also process it as unpacked characters requiring more than 8 bits.
|
|
|
|