141–150 of 278 posts
I just want a phone number input box that will strip dashes for me. Many go to the effort of having an error message pop up that says "no dashes or parentheses allowed." So they went to the effort of writing special case code to notice and handle this ... by giving instructions to the person, instead of the computer.
Earlier quoted context omitted.
I just stick an "A!" on the end of my otherwise complex password to satisfy these stupid rules. The worst is when they don't even allow spaces.
The worst rule that I have seen was that you can't have the same character next to each other. So "Pasword1234#" was "strong" password, but "ha_ivrkbs(i5HzJzee%Ii3jsk#7jaot" was considered weak - note "ee" in the middle of string.
No idea how maby bits of entropy it removes but it's absurd.
Earlier quoted context omitted.
>>> exit Use exit() or Ctrl-Z plus Return to exit
In Python, it is expected that typing an identifier will not cause an action to happen... so this is consistent with that expectation.
I'd love to find (never looked...) a python3 repl where `print`, `dir`, `help` all behave like python2's `print`, since they're debug/lookup tools. It's rather often I'll open a terminal and want to check one of those things, and... typing () characters just adds significant effort (for lack of better description).
I just want a phone number input box that will strip dashes for me. Many go to the effort of having an error message pop up that says "no dashes or parentheses allowed." So they went to the effort of writing special case code to notice and handle this ... by giving instructions to the person, instead of the computer.
I thought the same, and was surprised to find the problem here seems to be that there's no part of the HTML spec to set the allowable characters in a text input. So JavaScript to intercept keypresses or postprocess the string is risky at best and often poorly implemented. If it was in HTML it could be reliable, and have a unified behaviour when text is pasted in. For phone numbers there is a "tel" input, so the undes…
Earlier quoted context omitted.
Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?
They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.
HeLLo, heLLo, hEllO, HEllO all normalize to heLLo
Earlier quoted context omitted.
Yup. My role of accepting phone numbers is `input.replace(/[^0-9+]/g, "")`. It might strip some expected information in rare cases but good enough for me. This works for a lot of other things that people format wildly like Canadian postal codes (which are A1A 1A1 format but many places require presence or absence of a space), credit cards (strip the spaces) and so many other fields.
Why not simply leave it as the user input the value? Validation is one thing, but silently dropping information cannot possibly be helpful for the person that then has to call this number. I agree it should work for any phone number I've ever encountered, but just why
This is a well-understood feature. Facebook does the same thing[0]. Quote: Facebook actually accepts three forms of your password: * Your original password. * Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word. * Your original password with the case reversed, for those with a caps lock key on. [0]: https://www.zdnet.com/a…
Earlier quoted context omitted.
Most certainly not. Those systems normally work by A) you providing the old password for verification or B) storing hashes of password substrings.
This sounds like a combinatorial explosion situation for longer passwords and longer changes required.
Ever call Fidelity phone support and hear "enter your password on the keypad"? That means collapsing ~62 chars into 10 char options, a massive space reduction. Then there's the fact that many banking sites (BofA, IIRC) only used the first 8 char of your password anyway.
Does this also mean they probably store passwords in clear text? Because there's no way to normalize the numeric passwords back to letters and symbols.
Earlier quoted context omitted.
They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.
I think that’s a likely route. It’s a question of what is more efficient, compute of hash or storage/retrieval and comparison to multiple. To implement, choice of storing three hashes or computing n * hashes where n < 1, the probability of getting a match before having to try another.